[Bug-gforth] [bug #23015] libltdl can't load libc

[Anton Ertl]

Update of bug #23015 (project gforth):

                  Status:                    None => Confirmed              
             Assigned to:                    None => anton                  

    _______________________________________________________

Follow-up Comment #2:

That's an issue with the way that we use libltdl, and the way that
libltdl is implemented:

First, we use lt_dladvise_ext(), which supposedly appends the right
extension for the platform; under Linux it tries to append .la or .so,
so one would hope that using "libc" as a name works on all systems,
but it does not under Linux (I have been in discussion with the
dlopen/glibc maintainers and the libtltdl maintainers over this, and
things are complicated); if you try to apply it to libc.so.6, it tries
libc.so.6.so and fails.  So maybe the lt_dladvise_ext() feature is not
as useful as one might think after all.

For MacOS X, I'll just copy what I was told myself:

|You should be aware however, that opening libraries (as opposed
|to modules) is not entirely portable.  For example Mac OS X has
|foo.dylib for shared libraries that will be opened by the linker
|at run time, and foo.so for modules that are openable with dlopen()
|and equivalent.
|
|On architectures with a runtime loader that can't handle dependent
|libraries (for example a math.so module that was linked with -lm),
|lt_dlopen() et. al. will portably open those dependency libraries
|(eg libm.so) provided you installed and open the appropriate .la
|file.
|
|In other words, lt_dlopen("math.la") will automatically load libm.so
|on those hosts that require it without forcing you to write non-
|portable code.

Hmm, that inspires the idea that I could tack on the linking with -lm
etc. to the libtool invocation in libcc.fs; that might be portable.
This won't help for libffi.fs or fflib.fs, but these are intended as
legacy support only.

Anyway, libltdl seems to play only well with .la files, and everything
else is luck.

Concerning unix/sockets.fs, the long-term plan is to do everything
through libcc.fs, and to use files containing the Forth part of the
declarations that are semi-automatically generated from the .h files.
I have a student who is working on the semi-automatic tool.

In the short term, one can convert that file manually, or one can just
leave it alone and wait for the tool support.  Also, libcc.fs still is
not really release-ready (no multi-user support, not even safe against
several processes).


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?23015>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/