bugGforth - Bugs: bug #23015, libltdl can't load libc


bug #23015: libltdl can't load libc

Submitter:  Darren Bane <dbane>
Submitted:  Tue 22 Apr 2008 08:56:08 AM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  anton
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Tue 29 Apr 2008 08:10:05 PM UTC, comment #4: 

I have applied the unix/socket.fs part of your patch and extended it.

I did not apply the lib.fs part; I have taken out the usage of
lt_dladvise_ext(), so the part you wanted to remove should work again.

For library name portability, I now use -l<lib> in the libtool command
(and provide ADD-LIB and CLEAR-LIBS words for that).  If you use
libffi.fs or fflib.fs, you just have to live with non-portable library
names; lt_dladvise_ext() does not work for that (at least for now).

Anton Ertl <anton>
Project Administrator
Tue 22 Apr 2008 09:04:19 PM UTC, comment #3: 

I've attached the patch that I mentioned earlier.

I knew about lt_dladvise_ext(), it's what allows the same code to load Mac OS X (ending in .dylib) and Linux (ending in .so) shared objects. I had forgotten about the situation on Mac OS X with bundles (and the bundle_loader flag to the linker) versus dynamic libraries, but it's coming back to me now. Oh well.

Hopefully your wrapper generator will turn out as useful as swig, but without the bloat. The big difference I'd see between gforth and the commercial compilers would then be the lack of OS thread (and hence multicore) support. But on the other hand, you're 64-bit :-)

(file #15508)

Darren Bane <dbane>
Tue 22 Apr 2008 02:45:46 PM UTC, 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
|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).

Anton Ertl <anton>
Project Administrator
Tue 22 Apr 2008 09:04:11 AM UTC, comment #1: 

I just noticed one other difference between the libraries that will load and those that won't. The ones that load all have .la files associated with them, I don't know if that's relevant or not.

Darren Bane <dbane>
Tue 22 Apr 2008 08:56:08 AM UTC, original submission:  

Tested on both Mac OS X and amd64 Linux. Trying to load lib.fs or unix/socket.fs fails because libc (both .so.6 and .dylib) can't be loaded. However, loading other libraries (e.g. ones I've made myself, libffi from MacPorts, or ones generated by libcc.fs) work fine.

The libraries certainly exist. The problem may be that the libraries that won't load are stripped, but I don't know for sure.

I could easily have deleted the calls defining the libc word and replaced the socket imports in unix/socket.fs with the equivalent using the documented libcc.fs interface, but I'm not sure whether that is the intention or not.

Darren Bane <dbane>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #15508:  patch-libc.diff added by dbane (2KiB - application/octet-stream - Path to not try load libc any more)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by anton (Posted a comment)
  • -email is unavailable- added by dbane (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-04-29 anton StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2008-04-22 dbane Attached File- Added patch-libc.diff, #15508
    2008-04-22 anton StatusNone Confirmed
        Assigned toNone anton

    Back to the top

    Powered by Savane 3.9