I'm using a program that uses libltdl (from libtool) to wrap calls to
dlopen (e.g. lt_dlopenext) and dlsym and it is utterly unable to dlopen
"standard" shared libraries.
Gentoo (probably following upstream glibc) has been putting linker
scripts where shared libraries were origniall
): Add lt_vtable.h.
* libltdl/ltdl.mk (libltdl_libltdl_la_SOURCES): Likewise.
* libtoolize.in (all_pkgltdl_files): Likewise.
* libltdl/loaders/dld_link.c: Replace get_vtable prototype with lt_vtable.h
include.
* libltdl/loaders/dlopen.c, libltdl/loaders/dyld.c,
libltdl/loaders/load_add_on.c, libltdl
The lt_dlloader.h API already says these have const return values, and
the main ltdl.c module defines its get_vtable in that way, so update all
of the loaders to match.
* libltdl/loaders/dld_link.c (get_vtable): Add const.
* libltdl/loaders/dlopen.c, libltdl/loaders/dyld.c,
libltdl/loaders
This is an automated email from the git hooks/post-receive script.
vapier pushed a commit to branch master
in repository libtool.
The following commit(s) were added to refs/heads/master by this push:
new 1879a0e6 libltdl: delete use of ^L
1879a0e6 is described below
commit
GNU indent does not process this well, and nothing else in the tree
uses this convention, so drop it.
(GNU indent is enforced by gnulib when running `make distcheck`.)
* libltdl/ltdl.c: Delete ^L.
* libltdl/ltdl.h: Likewise.
---
libltdl/ltdl.c | 1 -
libltdl/ltdl.h | 2 --
2 files changed, 3
Fix for undefined symbol strneq. The original working code in 97ade81
used !strcmp() to check for string equality before it was incorrectly
replaced with strneq(). This loader is built on OS X before 10.4.
---
libltdl/loaders/dyld.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
be great for our
test coverage too!
Yes, I was kind of surprised that evidently the most involved preloader
test was demo. I thought that libltdl basically worked with MSVC,
as long as you took care to apply the correct #ifdef madness. But that
proved very wrong when you moved demo/ to demo.at
(_LT_CMD_GLOBAL_SYMBOLS) [MSVC]: Adjust
lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix so that they
fill in (void*) 0 for data symbols which need to be relocated
at runtime by the above lt_syminit.
* libltdl/loaders/preopen.c (add_symlist): Look up
I'm looking for is feedback. Is it acceptable to add a
new virtual @INIT@ entry like this? I.e. is this approach
workable or should I just drop it?
I have no objections, except perhaps that it would be good to check
that the ABI doesn't stop pre-patch libltdl from preloading libraries
built
On 10/02/2012 05:34 PM, Michael Haubenwallner wrote:
here's a set of patches to fix the two major problems with current AIX support
in libtool, that is:
*) libltdl: lt_dlopen() does work /with/ runtime linking (LDFLAGS=-brtl) only.
*) libtool: /Without/ runtime linking, there is some
Hi,
here's a set of patches to fix the two major problems with current AIX support
in libtool, that is:
*) libltdl: lt_dlopen() does work /with/ runtime linking (LDFLAGS=-brtl) only.
*) libtool: /Without/ runtime linking, there is some versioning support, but
still far from being ideal
Hello,
I am working at embedding libltdl inside our project (hwloc, an Open MPI
subprojet). Our plugins are not expected to be enabled in the most
common cases. So I am trying to see if the libltdl sub-configure could
be skipped entirely unless really needed (when plugins are enabled, and
libltdl
On Wed, 22 Aug 2012, Brice Goglin wrote:
Hello,
I am working at embedding libltdl inside our project (hwloc, an Open MPI
subprojet). Our plugins are not expected to be enabled in the most
common cases. So I am trying to see if the libltdl sub-configure could
be skipped entirely unless really
On 2012-08-22 15:12 +0200, Brice Goglin wrote:
I am working at embedding libltdl inside our project (hwloc, an Open MPI
subprojet). Our plugins are not expected to be enabled in the most
common cases. So I am trying to see if the libltdl sub-configure could
be skipped entirely unless really
Le 22/08/2012 16:32, Nick Bowler a écrit :
On 2012-08-22 15:12 +0200, Brice Goglin wrote:
I am working at embedding libltdl inside our project (hwloc, an Open MPI
subprojet). Our plugins are not expected to be enabled in the most
common cases. So I am trying to see if the libltdl sub-configure
On 2012-08-22 20:26 +0200, Brice Goglin wrote:
Le 22/08/2012 19:44, Nick Bowler a écrit :
On 2012-08-22 18:32 +0200, Brice Goglin wrote:
Le 22/08/2012 16:32, Nick Bowler a écrit :
[...]
Other than adding -I$(top_builddir) to CPPFLAGS, as a workaround you
could probably add something like
.
We likely have a couple months before the next major hwloc release
starts using libltdl, so I hope we'll have a better fix by then.
Regards
Brice
___
https://lists.gnu.org/mailman/listinfo/libtool
Hello,
I am fixing leaks in one of my software projects that embeds libltdl
2.4.2 to load plugins. I noticed that when the plugin depends on the
dynamic library that the main program doesn't depend on, valgrind
reports some leaks.
We created a small testcase reproducing the problem. It's
On Tue, 3 Apr 2012, Brice Goglin wrote:
I am fixing leaks in one of my software projects that embeds libltdl
2.4.2 to load plugins. I noticed that when the plugin depends on the
dynamic library that the main program doesn't depend on, valgrind
reports some leaks.
If the main program
Le 03/04/2012 23:13, Bob Friesenhahn a écrit :
On Tue, 3 Apr 2012, Brice Goglin wrote:
I am fixing leaks in one of my software projects that embeds libltdl
2.4.2 to load plugins. I noticed that when the plugin depends on the
dynamic library that the main program doesn't depend on, valgrind
), the
leaks go away, so indeed the problem is likely outside of libltdl.
The important thing to test for is that if you load and unload this
module 1000 times, do you see 1000X as much leak or the same amount
as when loading/unloading one time?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us
dependency (libpci instead of libpthread), the
leaks go away, so indeed the problem is likely outside of libltdl.
The important thing to test for is that if you load and unload this
module 1000 times, do you see 1000X as much leak or the same amount
as when loading/unloading one time?
As I
Sorry I wasn't able to break this up into smaller pieces without
leaving the tree with failing tests between.
In addition to moving the autoconf macro directory into the
place expected by GNU developers ($top_srcdir/m4), we also
simplify libtoolize somewhat by having libltdl use whatever
In addition to moving the autoconf auxiliary script directory
into the place expected by GNU developers ($top_srcdir/build-aux)
we also simplify libtoolize somewhat by having libltdl use
whatever directory was specified by the parent project. This is
much more flexible, allows libltdl client
Hi Stefano,
On 2 Nov 2011, at 16:29, Stefano Lattarini wrote:
On Wednesday 02 November 2011, Gary V wrote:
I like to make sure the tree is capable of passing `make distcheck' after
every patch,
And this is a very good policy, with which I fully agree. What I meant
was: wouldn't be
Hi Gary.
On Wednesday 02 November 2011, Gary V wrote:
package_revision=`$SHELL $ac_aux_dir/git-version-gen .tarball-version`
diff --git a/libltdl/.gitignore b/libltdl/.gitignore
index 2f39096..5795dbc 100644
--- a/libltdl/.gitignore
+++ b/libltdl/.gitignore
@@ -2,5 +2,4
On Wednesday 02 November 2011, Gary V wrote:
Hi Stefano,
On 1 Nov 2011, at 21:57, Stefano Lattarini wrote:
Hi Gary, hope you won't mind few nits from an outsider ...
Absolutely not, any and all feedback is always extremely welcome. Thank you.
On Tuesday 01 November 2011, Gary V wrote:
) alongside your parent
project's files in ltdl/config.
Gary,
Due to libtool's spotted past, many projects check the 'libtoolized'
files (including libltdl) into their project's source control system,
including rather crippled systems like CVS. Libtool files then become
much more carefully
On 11/01/2011 08:19 AM, Gary V. Vaughan wrote:
This next series of changesets is the beginning of modelling the directory
and filenaming conventions of Libtool to match what is done by other
prominent GNU projects... this means that gnulib scripts will require less
tweaking and configuration, so
.
* libltdl/m4: Moved to it's parent directory.
s/it's/its/.
* tests/cdemo/Makefile.am, tests/demo/Makefile.am,
tests/depdemo/Makefile.am, tests/f77demo/Makefile.am,
tests/fcdemo/Makefile.am, tests/mdemo/Makefile.am,
tests/mdemo2/Makefile.am, tests/pdemo/Makefile.am,
tests/tagdemo
), the libltdl 'config'
directory is treated as a well defined public interface which is
referenced by (and shared by) exisiting package configure scripts.
For example, this is how the configure.ac refers to it in my package:
# Directory where autotools helper scripts lives.
AC_CONFIG_AUX_DIR([ltdl
) in order to improve build times and reduce redundant waste. For
packages (such as mine), the libltdl 'config' directory is treated as a well
defined public interface which is referenced by (and shared by) exisiting
package configure scripts. For example, this is how the configure.ac refers
Hi Chuck,
On 1 Nov 2011, at 22:15, Charles Wilson wrote:
On 11/1/2011 10:57 AM, Stefano Lattarini wrote:
Is `ln -s' portable to e.g., MinGW? Or is the bootstrapping process
not meant to work there anyway, so we can just not care?
No, bootstrapping is supposed to work (and, until quite
Hi Eric,
On 1 Nov 2011, at 22:03, Eric Blake wrote:
On 11/01/2011 08:19 AM, Gary V. Vaughan wrote:
This next series of changesets is the beginning of modelling the directory
and filenaming conventions of Libtool to match what is done by other
prominent GNU projects... this means that gnulib
(exclude_file_name_regexp--sc_prohibit_test_minus_ao):
Adjust path.
* configure.ac (AC_CONFIG_MACRO_DIR): Adjust.
* libltdl/m4: Moved to it's parent directory.
s/it's/its/.
Oops. Applied.
* tests/cdemo/Makefile.am, tests/demo/Makefile.am,
tests/depdemo/Makefile.am, tests/f77demo/Makefile.am,
tests/fcdemo
On 06/14/2010 04:41 PM, Peter O'Gorman wrote:
dlopen nonexisting file
dlopen existing file
check dlerror()
Ok, systems that return an error in this case:
Solaris, AIX, HPUX/IA64, FreeBSD
systems that don't return an error:
HP-UX/HPPA, Tru64 5.1, IRIX 6.5, linux/glibc, Mac OS X.
Whee.
On Tue, 2010-06-15 at 20:14 +0200, Ralf Wildenhues wrote:
Please note that in general, it is impossible for configure tests to be
-Werror clean. That is not only due to the sheer amount of possible
erros from different GCC compiler versions (not to speak of others),
different sets of warning
On 06/16/2010 01:48 AM, Philip Allison wrote:
On Tue, 2010-06-15 at 20:14 +0200, Ralf Wildenhues wrote:
Please note that in general, it is impossible for configure tests to be
-Werror clean. That is not only due to the sheer amount of possible
erros from different GCC compiler versions (not
The test program for whether a program can dlopen itself generates a
compiler warning, which turns into a failure when building with -Wall
-Werror in CFLAGS. The error is in the libltdl/m4/libtool.m4 file, and
is due to the fnord function containing an unused variable. Please
find attached
have to do things that are only
half-decent C. Thus we strongly recommend to add -Werror only at 'make'
run time and not at configure time already.
That said,
2010-06-15 Philip Allison philip.alli...@smoothwall.net
* libltdl/m4/libtool.m4 (_LT_TRY_DLOPEN_SELF): Fix unused
On 06/10/2010 12:33 AM, Peter O'Gorman wrote:
At least glibc and Mac OS X reset the dlerror() string to NULL every
time a dl*() api is called (I will check what other systems do in the
next few days). This is so programmers can do:
Sigh, but FreeBSD doesn't.
dlopen nonexisting file
dlopen
other error that occurred long before the
call to dlsym().
Interesting. IIRC, Thomas chose the semantics and API of libltdl to closely
match the Unix dlfcn.h calls so that it could be used as a direct replacement
by a client with very little editing. If glibc and OS X (which to my mind
Aside: I'm leaning away from upholding the
'drop-in-with-minimum-edits' philosophy for my rewrite, since the
dlfcn.h API seems like a pretty bad design to me. After all, all
people really need to do is call functions with a known name and
known signature which happen to be in another library.
Hi Peter,
On 10 Jun 2010, at 21:15, Peter O'Gorman wrote:
Aside: I'm leaning away from upholding the
'drop-in-with-minimum-edits' philosophy for my rewrite, since the
dlfcn.h API seems like a pretty bad design to me. After all, all
people really need to do is call functions with a known name
On 06/10/2010 09:45 AM, Gary V. Vaughan wrote:
I think it would be better in c++.
No, that would mean you have to jump through hoops to use it from C.
And it would make me cry myself to sleep at night. I avoid C++, Perl,
McDonalds and suicide bomber recruiters as much as I possibly can. I'm
On 06/10/2010 02:28 PM, Bob Friesenhahn wrote:
On Thu, 10 Jun 2010, Peter O'Gorman wrote:
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like file not found where the
actual problem might be something completely different, and a
On Thu, 10 Jun 2010, Peter O'Gorman wrote:
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like file not found where the actual
problem might be something completely different, and a reasonable error
string may be readily available
, it looks like libltdl attempts to save error state across
calls to lt_*() functions, and generally does not do it well.
This patch resets the error every time a public ltdl function is called,
and when setting an error tests if it is already set and doesn't
overwrite it if it is. The fist error
configure the subpackage at
all, then a 'make dist' won't package up the included libltdl, which
means the package tarball can't be reproduced. Not totally sure about
this, but changing this would be an API change and require a big
warning, so probably a new configure switch.
Lastly, the change
The subject says it all. Comments appreciated.
Thanks!
Ari
--
diff --git a/libltdl/m4/ltdl.m4 b/libltdl/m4/ltdl.m4
index 111fac1..67317c0 100644
--- a/libltdl/m4/ltdl.m4
+++ b/libltdl/m4/ltdl.m4
@@ -384,8 +384,11 @@ dnl Don't require this, or it will be expanded earlier
than the code
dnl
?
OK to commit?
Thanks,
Ralf
Improve parsing of .la files in libltdl.
* libltdl/ltdl.c (trim): Do not dump core upon missing quote in
module .la file.
* tests/lalib-syntax.at (syntax of .la files): New file, new
test.
* Makefile.am (TESTSUITE_AT): Add tests/lalib
. Proposed patch. What other things do you know about that
are mishandled?
OK to commit?
The fix and the tests look quite good and useful to me. I don't
currently know of other parsing issues.
As long as the application can trust that libltdl will search for .la
files in secure locations
Hallo Ralf,
On 1 Dec 2009, at 06:39, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Tue, Dec 01, 2009 at 12:02:42AM CET:
On 30 Nov 2009, at 16:01, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Mon, Nov 30, 2009 at 06:29:54PM CET:
On 29 Nov 2009, at 16:27, Ralf Wildenhues wrote:
-
slist this way that
I can look at.
BTW, so far I haven't removed anything that wouldn't be fixable with a
cast or two.
More generally, I am really convinced that libltdl quality is the way it
is only because authors never really cared to ensure their code really
does what it was supposed to do
* Gary V. Vaughan wrote on Tue, Dec 01, 2009 at 12:02:42AM CET:
On 30 Nov 2009, at 16:01, Ralf Wildenhues wrote:
If (i) does work, then likely my patch is broken after all; so I guess I
will have to wait with applying.
I think that subject to the feedback you have received, the patch
. If this is not ok with you,
then please complain loudly.
Whispering a complaint, see below...
*snip*
Test and fix slist.c.
* libltdl/libltdl/slist.h: Include stddef.h, for size_t.
(slist_remove): Return pointer to SList, not void.
* libltdl/slist.c: Include stdlib.h
Hallo Ralf!
On 29 Nov 2009, at 16:27, Ralf Wildenhues wrote:
A first step at more libltdl coverage: better coverage for the slist
API.
Excellent, and thank you.
Notes:
- I did find bugs in slist.c, albeit serious ones only in code not used
elsewhere in libltdl.
Ick. I think
-check_PROGRAMS = tests/test-slist
-tests_test_slist_SOURCES = \
- tests/test-slist.c \
- libltdl/slist.c
-
tests/cdemo-undef-exec.log:tests/cdemo-undef-make.log
tests/cdemo-undef-make.log:tests/cdemo-undef.log
tests/cdemo-undef.log: @ORDER@ tests/cdemo-shared-exec.log
diff --git
in this case), while also avoiding hand writing the glue code
to add the next pointers into structures that will be fed to SList.
I'm not sure I agree that this is elegant, but maybe I just
misunderstand the code.
But all of this is so unimportant to the libltdl code quality that I
prefer we just
Hallo Ralf,
On 30 Nov 2009, at 16:01, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Mon, Nov 30, 2009 at 06:29:54PM CET:
On 29 Nov 2009, at 16:27, Ralf Wildenhues wrote:
- slist_remove should IMVHO return an SList *, because otherwise there
is no way to avoid a memory leak. APIs that
Hi Peter,
* Peter O'Gorman wrote on Mon, Nov 16, 2009 at 05:06:26PM CET:
If you happen to be stuck using an older libltdl for some reason,
the attached untested patch should give you the same changes in
behavior as the badly numbered 2.2.6b release.
If this passes the branch-1-5 testsuite
If you happen to be stuck using an older libltdl for some reason, the
attached untested patch should give you the same changes in behavior as
the badly numbered 2.2.6b release.
Peter
--
Peter O'Gorman
http://pogma.com
diff -urN libtool-1.5.26.orig/libltdl/ltdl.c libtool-1.5.26/libltdl/ltdl.c
to execute quite well
under Solaris (better than a static build) when using loadable
modules. Now using any loadable modules via libltdl makes the minimum
program execution time 4X slower, and this is when loading only two
modules. Looking at system calls showed massive amounts of 'stat
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
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
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)
Hello Will,
* Will Mason wrote on Mon, May 11, 2009 at 06:47:58AM CEST:
I've been using a project with autoconf, automake and libtool for some time.
Today I added libltdl to my code. I ran libtoolize --ltdl --copy. My
configure.ac has this:
LT_CONFIG_LTDL_DIR([libltdl])
LT_INIT([dlopen
On Mon, May 11, 2009 at 1:10 AM, Ralf Wildenhues ralf.wildenh...@gmx.dewrote:
Hello Will,
* Will Mason wrote on Mon, May 11, 2009 at 06:47:58AM CEST:
I've been using a project with autoconf, automake and libtool for some
time.
Today I added libltdl to my code. I ran libtoolize --ltdl
.
Today I added libltdl to my code. I ran libtoolize --ltdl --copy. My
configure.ac has this:
LT_CONFIG_LTDL_DIR([libltdl])
LT_INIT([dlopen])
LT_LANG([C++])
LTDL_INIT([recursive])
When I build on Mac OS X, everything is great. It all works perfectly.
When
I build
:
I've been using a project with autoconf, automake and libtool for
some time.
Today I added libltdl to my code. I ran libtoolize --ltdl --copy. My
configure.ac has this:
LT_CONFIG_LTDL_DIR([libltdl])
LT_INIT([dlopen])
LT_LANG([C++])
LTDL_INIT([recursive])
When I
Hello,
I've been using a project with autoconf, automake and libtool for some time.
Today I added libltdl to my code. I ran libtoolize --ltdl --copy. My
configure.ac has this:
LT_CONFIG_LTDL_DIR([libltdl])
LT_INIT([dlopen])
LT_LANG([C++])
LTDL_INIT([recursive])
And my Makefile.am has
Hello,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
The question now is: will people be able to build tarballs that come
with Libtool 2.2 with ltdl.h from Libtool 1.5?
The answer is actually no, precisely because of this additional line
in ltdl.h (missing from 1.5) [*]:
#define
Hello,
Ralf Wildenhues [EMAIL PROTECTED] writes:
* Ludovic Courtès wrote on Tue, Nov 25, 2008 at 09:38:53AM CET:
The Guile project is considering moving from Libtool 1.5 to 2.2. We
noticed subtle incompatibilities when people tried to compile Guile
tarballs (which use Libtool 1.5 up to now)
Something that may be of interest:
http://bugs.gentoo.org/show_bug.cgi?id=212723
especially my comment #8.
For non-Gentoo users:
eautoreconf (if I were to simplify it) is something like this:
- first call aclocal (with additional -I options, if needed)
- then check for libtool use and call
Hello,
The Guile project is considering moving from Libtool 1.5 to 2.2. We
noticed subtle incompatibilities when people tried to compile Guile
tarballs (which use Libtool 1.5 up to now) with ltdl.h from Libtool
2.2 [0].
The question now is: will people be able to build tarballs that come
with
On Tue, 25 Nov 2008, Ludovic Courtès wrote:
The question now is: will people be able to build tarballs that come
with Libtool 2.2 with ltdl.h from Libtool 1.5?
I don't think there was ever any intention for libtool 2.2.X to work
with libltdl from libtool 1.5.X. If libltdl is not bundled
On Tue, 25 Nov 2008, Ludovic Courtès wrote:
I don't think there was ever any intention for libtool 2.2.X to work
with libltdl from libtool 1.5.X. If libltdl is not bundled with the
package, then it should be possible to use an already installed
libltdl from libtool 1.5.X.
What do you mean
Hello Ludovic,
* Ludovic Courtès wrote on Tue, Nov 25, 2008 at 09:38:53AM CET:
The Guile project is considering moving from Libtool 1.5 to 2.2. We
noticed subtle incompatibilities when people tried to compile Guile
tarballs (which use Libtool 1.5 up to now) with ltdl.h from Libtool
2.2 [0].
Hi Peter,
* Peter O'Gorman wrote on Sat, Aug 23, 2008 at 11:59:00PM CEST:
On systems without argz we were exporting unmangled symbols argz_count
and argz_add from libltdl. Not really a good idea. Rather than mangle
the names, since we do not use either function, they were removed.
Subject
Hi Peter,
* Peter O'Gorman wrote on Sat, Aug 23, 2008 at 11:59:00PM CEST:
Subject: [PATCH] Allow for extensions other than .a for preloaded modules.
* libltdl/m4/ltdl.m4 (_LTDL_SETUP): Define LT_LIBEXT.
* libltdl/ltdl.c (lt_dladvise_preload): Use it.
Reported by Ralf Wildenhues.
OK, thanks
Ralf Wildenhues wrote:
Yes, certainly. I think a NEWS entry would be good, too, as well as
a test so we don't regress again. What do you think of this? You
can squash it into your patch when you commit.
Thanks.
The test doesn't work on many systems (only those that need argz.c,
and
* Peter O'Gorman wrote on Tue, Aug 26, 2008 at 06:24:11PM CEST:
Ralf Wildenhues wrote:
I'd like this to fail for me on darwin (more likely to notice it), so I
will probably add:
+AT_CHECK([eval $NM \\$argz_o\ | $global_symbol_pipe],
+[], [stdout], [ignore])
+AT_CHECK([grep ^T
Peter O'Gorman wrote:
On systems without argz we were exporting unmangled symbols argz_count
and argz_add from libltdl. Not really a good idea. Rather than mangle
the names, since we do not use either function, they were removed.
But wasn't there a thread back in June where we explicitly added
On Sun, 24 Aug 2008, Charles Wilson wrote:
But wasn't there a thread back in June where we explicitly added a bunch
of argz functions, so that (a) we would be using the same file as
gnulib, and (b) that file would have a complete argz implementation?
I recall that it was decided that it was
Peter O'Gorman wrote:
So, with the functions also removed from the header, ok?
Fine by me -- but I can't give official approval. g
--
Chuck
Hi,
On systems without argz we were exporting unmangled symbols argz_count
and argz_add from libltdl. Not really a good idea. Rather than mangle
the names, since we do not use either function, they were removed.
And as Ralf reported previously, preloaded modules can have the .lib
extension
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, I'm working on a cross-platform game, and for plugin loading, I was
hoping to use libltdl, since Win32 DLL loading is a pain to work with.
However, it only builds on Windows with mingw or the cygwin system, and
this is sort of a deal-breaker
Hello Corbin,
* Corbin Simpson wrote on Tue, Jul 08, 2008 at 09:03:01AM CEST:
Hi, I'm working on a cross-platform game, and for plugin loading, I was
hoping to use libltdl, since Win32 DLL loading is a pain to work with.
However, it only builds on Windows with mingw or the cygwin system
for that compiler. I've just recently started using libltdl in
my
project, though; and I'd like to build it using the same facilities as
the rest of the software.
Hmm... doesn't sound too easy :) at our company we use MS compilers
through a compiler frontend that mimics GCC/LD, so we can use
[snip]
Historically (i.e. prior to libtool 2.x), I've found that those shell
environments have not been up to the task of building my project with
the Microsoft compiler. So I've maintained a Visual C++ project file
build for that compiler. I've just recently started using libltdl in
my
* Braden McDaniel wrote on Fri, Jun 20, 2008 at 10:20:13PM CEST:
Ralf Wildenhues wrote:
* Braden McDaniel wrote on Fri, Jun 20, 2008 at 11:03:04AM CEST:
[snip]
Yes, unfortunately there is still a ways to go.
Btw. @Ralf: how is integration of the windows patchery going? :) has
there been
. Is this
intentional? (It's a problem here because there is no argz.h.)
Yes. Libtool provides a replacement argz.h, see libltdl/argz_.h.
I did. But argz_.h is not getting included by lt__glibc.h; argz.h is.
Does the configure build copy argz_.h to argz.h?
Yes. The copying is done so that, if the system
I've built libltdl with the Microsoft compiler and I'm trying to use it
to load a DLL. I am calling lt_dlforeachfile; the problem seems to be
that the call to loader-module_open in tryall_dlopen is failing. That
call resolves to presym_open. This call is failing because
preloaded_symbols is set
Hi Braden,
* Braden McDaniel wrote on Fri, Jun 20, 2008 at 09:37:59AM CEST:
I've built libltdl with the Microsoft compiler and I'm trying to use it
to load a DLL.
without having looked at this at all (and not sure whether I can):
please give us rope so this can be reproduced: are you using
On Fri, 2008-06-20 at 09:52 +0200, Ralf Wildenhues wrote:
Hi Braden,
* Braden McDaniel wrote on Fri, Jun 20, 2008 at 09:37:59AM CEST:
I've built libltdl with the Microsoft compiler and I'm trying to use it
to load a DLL.
without having looked at this at all (and not sure whether I can
a replacement argz.h, see libltdl/argz_.h.
How come you cannot use a shell environment like MinGW or SFU to build
Libtool? You're going to have a pretty rough time emulating the rather
involved build logic for it.
Cheers,
Ralf
___
http://lists.gnu.org
. Libtool provides a replacement argz.h, see libltdl/argz_.h.
I did. But argz_.h is not getting included by lt__glibc.h; argz.h is.
Does the configure build copy argz_.h to argz.h?
How come you cannot use a shell environment like MinGW or SFU to build
Libtool? You're going to have a pretty
For GraphicsMagick I need to maintain a GraphicsMagick-config script
which contains such things as the list of libraries necessary to link.
The conditionally installed libltdl seems to make this difficult to
figure out.
If enable_ltdl_convenience is 'yes' then it is wrong to list -lltdl
Hi Bob,
On 3 May 2008, at 17:40, Bob Friesenhahn wrote:
For GraphicsMagick I need to maintain a GraphicsMagick-config script
which contains such things as the list of libraries necessary to
link. The conditionally installed libltdl seems to make this
difficult to figure out.
I think
On Sat, 3 May 2008, Gary V. Vaughan wrote:
Sane options are to link against the installed libltdl if it is good enough
(whatever that means) or use a convenience libltdl otherwise.
I agree with that. Otherwise people may accidentally interfere with a
formally installed libltdl maintained
1 - 100 of 477 matches
Mail list logo
