I posted a bug report with the same subject several days ago to the
bug-libtool list (with data) but no discussion ensued so I will open
the issue for broader discussion here.
I was observing very poor execution performance of the modules-based
build of my application under Solaris. It used t
Doing some investigation under Linux, I see that libltdl does the same
wrong things under Linux except that Linux employs some algorithms
which makes doing the wrong things much less expensive than under
Solaris. Linux prunes directories in the search path which were found
to not exist from la
Bob Friesenhahn wrote:
Doing some investigation under Linux, I see that libltdl does the same
wrong things under Linux except that Linux employs some algorithms
which makes doing the wrong things much less expensive than under
Solaris. Linux prunes directories in the search path which were found
Here is what happens when an uninstalled module gets loaded under
FreeBSD:
access("/home/bfriesen/build/GraphicsMagick-16-modules/coders/xc.la",4) = 0
(0x0)
open("/home/bfriesen/build/GraphicsMagick-16-modules/coders/xc.la",O_RDONLY,0666)
= 3 (0x3)
access("/home/bfriesen/build/GraphicsMagick-1
On Sun, 25 Oct 2009, Howard Chu wrote:
Yeah, I recall noticing all this in the past. That's why I usually
delete .la files after build time and make sure they never get
installed. On platforms where the dependent shared libraries are
already listed inside a shared library's dynamic loader sec
On Sun, 25 Oct 2009, Howard Chu wrote:
Yeah, I recall noticing all this in the past. That's why I usually delete .la
files after build time and make sure they never get installed. On platforms
where the dependent shared libraries are already listed inside a shared
library's dynamic loader sec
It is pretty clear that lt_dlopenadvise() in ltdl.c intends to try
doing a dlopen with ARCHIVE_EXT. The documentation in the code says:
/* If FILENAME has an ARCHIVE_EXT or MODULE_EXT extension, try to
open the FILENAME as passed. Otherwise try appending ARCHIVE_EXT,
and if a file is sti
On 10/25/2009 09:04 PM, Bob Friesenhahn wrote:
The conditions in the code can simply be reversed so that the shared
library extension is tested first. Does anyone know a reason for the
current order?
It's been a while since I've looked at libltdl, so the following may not
be correct.
It tr
