need clarify about libdl and all dlopen/dlclose calls

@All
Find out lately that one project i want to build rely on usage of those dlopen()/dlclose() and dlsym() functions, and on linking line use "-ldl" for.

But i seems missed it in my current SDK.

One i found is on os4depot "libdl" from Chris Young from 2009. But i not sure if it expected that we use this one only ? No other ones ?

Or maybe there some way to use those functions without having "-ldl" but having dlopen/dlclose/dlsym working as expected (like adding some proto includes, etc ?)

I also remember (But can be very wrong), that libdl.a were presented in some older SDK versions, while for now seems not ?


EDIT: i found that newlib/include/ have dlfcn.h file, which contain defines for those functions, but i can't find in whole SDK libdl.a

libdl is for using functions from shared object libraries. libdl itself is a shared object, which is why you can't find it in the SDK. It resides in SYS:SObjs/

To make use of it, you have to use the linker option -use-dynld, then you can pass -ldl and use its functions.

@Cyborg
Something still wrong then.when you use -dl and -use-dynld this bring errors about missing -ldl. And if SDK didnt contain libdl.a or libdl.so, then its wrong, because you cant build any code which use it on anything, but only directly on aos4. Sdk already contain lot of sobjs then why no libdl.so then ?

For example, sdk come with libc.so. you building code with it, but then running it on os4 with libc.so coming with os4 instalation make thing not work. So there already problems, and i need to create sobjs dir and put there libc.so from sdk.

In other words cant see why there no libdl.so then in sdk as well

@kas1e
You also have DLOpen, DLClose, DLSym in elf.library,
don't know why it is there too, might be that they uses some other kind of arguments.
I do have libdl.so in sys:sobjs, is it perhaps an older version of elf.library.kmod in kickstart? elf library.kmod is from 27.10.2019 version 53.30
libdl.so is from 9.4.2013 version 53.4 I would suggest to try with elf.library.

@kas1e

Ok, what you then probably want is to install http://os4depot.net/?function=showfil ... nt/library/misc/libdl.lha in your SDK.

@trgswe
@Cyborg
@kas1e

Was this resolved?

I'm still wondering if elf.library took over the libdl functionality (so we can get rid of this library) or if it's a coincidence with rather unfortunate naming?

Thanks

@Raziel
I just use libdl from os4depot. Because seems in SDK, while proto files present, those dl functions only used for dynamic linking (so when sobjes in use). For static linking SDK do not have libdl.a , so i use one from os4depot.

@kas1e

Thanks, creating a link to the SOBJS: file was sufficient to make it find it (for dynamic builds)
I'm going to try it with ScummVM, maybe it'll give more stability...

@Raziel

Quote:

libdl is implemented by calls to elf library. There no name clash as the low level elf.library calls have a different case to libdl.

@broadblues

I'm sorry, I didn't quite understand.

Does that mean libdl is obsolete because it's superseded by elf.library functions?
Or do the elf.library dl implementation serve a similar but not the same purpose?

Or in short...can libdl be removed?

@Raziel
AFAIU libdl.a and libdl.so all internally calls elf.library.kmod, it is simply to make ports easier, since you can use makefiles etc which uses -ldl for linux etc.

@trgswe

Oh, ok...

Hmm, have to find out why .so access crashes with -ldl in place and doesn't if it's not used.

Maybe I'm mixing stuff again?

Yeah, I am also running into this issue. Only the header file exists.

If we are saying that these functions are implemented in the ELF.LIBRARY, that is fine. But - somewhere - when in the process of building a port, there needs to be some library that still provides a symbol of - for example - dlopen(). Presumably, that library would have already opened "ELF.LIBRARY" (possibly done implicitly anyway) and then would forward the call onto the ELF.LIBRARY's implementation.

The issue is that those functions must be resolved during the linking phase of the application that you are porting. SOBJS: is just a location that the ELF.LIBRARY searches for at runtime to open the Shared Object. We are talking about building, not running.

In the case that you compile statically - the default. You need a libdl.a, in the case that you are compiling with Shared Objects, via -use-dynld, you require a libdl.so; of course, if there is no libdl.so then -use-dynld would fall back to using libdl.a.

Is the canonical version the one from 2009 on Os4Depot? http://os4depot.net/?function=showfil ... t/library/misc/libdl.lha?

What concerns me is that Steven Solie's header file that I see in my SDK is from 2010, but the version of Os4Depot is 2009.

Outside of the amiga world, libdl is no longer required since those functions are implemented in libc itself. I am not sure that is the case for newlib - but I think @afxgroup 's CLIB2 does contains them in libc in which case, no libdl.(so|a) is needed.

@walkero
Bump for this. I know it is not your job, but I think we need to add this to the next SDK.

I was provided a libdl.a from afxgroup and even he did not know where it came from. That one worked, the one on OS4Depot did not link properly.

There is no libdl.a because under AmigaOS you cannot use the libdl functions if you are not using dynamic linking.

The SDK *should have* a link to libdl.so (in SDK:local/newlib/lib) though to enable linking of programs that use it. A copy of the file will work as well but is then at risk of going out of sync with the installed version.

@broadblues

Quote:
This needs to change, because there are situations where you might want to use libdl to load plugins/modules, but still want to statically link your program.

I've just encountered this now with code that built okay, but is asking for libatomic.so. I wanted everything to be statically linked, but one of the dependencies needs libdl.

EDIT: And the libdl.a on os4depot causes missing IElf symbol errors. Non-functional...

Hans

@Hans
You don't need a static libdl.a to load an additional library.
The program can be compiled completely statically but by dlopen through libdl.so an additional .so library for your needs.
I'm not quite sure if that's what you meant in what you wrote.

I used it to port https://os4depot.net/share/emulation/gamesystem/dgen_sdl.lha
Here is the program written for SDL1. The version for SDL2 flies through the static library “sdl12-compat” compiled from dgen where it calls SDL2.so from itself via libdl.so.
No one even noticed how it works. In the background, "sdl12-compat" runs the code is written under SDL1 and SDL2 is used.

Through snoopy you can see that the static head code itself does not need libdl - only when calling the SDL library

@smarkusg

Quote:
I want to statically link everything, but still be able to use dlopen(), etc.

To use libdl.so you need to dynamically link everything, which means that your program becomes dependent on a whole bunch of *.so's which the user must install. I do NOT want that.

Removing libdl.a was a mistake.

Hans

@Hans
Quote:No.
While it still might be possible to use dlopen(), etc. from libdl.a (or more directly IElf->DLOpen(), DLSysm(), DLClose() from elf.library) to load .so plugins, it's impossible for such .so plugins to call functions in the main executable on AmigaOS if the main executable wasn't build with -use-dynld.
For example the audio, video, PDF, etc. plugins of my AmigaOS 4.x port of OWB, only theoretically supported since nobody ever implemented those plugins, depend on back-calls of functions in the main executable.

@Hans
Quote:If elf.library support isn't included in libauto simply open it and the IElf interface yourself.
libdl.a is probably simply redirecting the functions to IElf->DLOpen(), DLSym() and DLClose().
But as I wrote it can only work for very simple shared objects/plugins which don't need to call functions from the statically linked main executable nor from statically linked libraries.