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.