it particularly or libltdl should be aware of that and not
register the sys_dl implementation.
It happens on openbsd 3.5.
Regards,
Guilhem Lavaux.
___
http://lists.gnu.org/mailman/listinfo/libtool
Currently libltdl will attempt to load any file you request it to (and
some you did not) under Windows. Libltdl is currently trying to load
.dll.a files when it loads a .la file. This causes problems.
While there are valid reasons for *Windows* programmers to load .exe
files and possibly
Bob Friesenhahn wrote:
Currently libltdl will attempt to load any file you request it to (and
some you did not) under Windows. Libltdl is currently trying to load
.dll.a files when it loads a .la file. This causes problems.
While there are valid reasons for *Windows* programmers to load .exe
On Wed, 29 Sep 2004, Howard Chu wrote:
Bob Friesenhahn wrote:
Currently libltdl will attempt to load any file you request it to (and
some you did not) under Windows. Libltdl is currently trying to load
.dll.a files when it loads a .la file. This causes problems.
While there are valid reasons
Libtool 2.0 (in development) provides a libltdl build scheme which is
intended to be integrated into the dependent package's configure/build
rather than providing a separate configure script. In this scheme
libltdl/Makefile is added to the package's configure.ac AC_OUTPUT
statement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8 Sep 2004, at 00:05, Bob Friesenhahn wrote:
It seems a shame that non-recursive packages must become recursive in
order to build libltdl. Using Automake includes, Automake
conditionals, and well-defined conventions, libltdl's Makefile.am
could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Greg, Peter,
On 18 Jul 2004, at 15:27, Peter O'Gorman wrote:
hope you come up with something for the -ldl issues.
The fix turned out to be pretty simple, I've just committed
libtool--gary--1.0--patch-34. Not tested on a linux box, but
by inspection
Gary V.Vaughan wrote:
../libdlloader.la:
cd ..; $(MAKE) $(MAKEFLAGS) libdlloader.la
I just applied this patch, hope you come up with something for the -ldl issues.
Peter
--
Peter O'Gorman - http://www.pogma.com
Index: ChangeLog
from Greg Eisenhauer [EMAIL PROTECTED]
* libltdl
Greg Eisenhauer [EMAIL PROTECTED]
* libltdl/loaders/Makefile.am: Use AM_MAKEFLAGS not MAKEFLAGS.
Grr, yes, I did just commit a ChangeLog entry with no actual changes. I have
now committed the change too.
diff -u -3 -p -u -r1.1 Makefile.am
--- Makefile.am 15 Jul 2004 12:14:48 -
for
me).
First the easy issue. I think there's a typo in the last line of
libtool/libltdl/loaders/Makefile.am. In particular in the recursive
invocation of make to build ../libdlloader.la
../libdlloader.la:
cd ..; $(MAKE) $(MAKEFLAGS) libdlloader.la
I changed $(MAKEFLAGS
Under Windows, if any object module has used __declspec(dllexport)
then this suppresses the default behavior of ld to export all symbols
and it only exports those with the above attribute. This is the case
with libltdl. The libltdl/ltdl.h header defines LT_SCOPE and uses it
throughout
I am trying to build a DLL which uses libltdl for dynamic loading of
other libtool modules. As a result I am first building libltdl as a
convenience library using
...
AC_LIBLTDL_CONVENIENCE
AC_SUBST(INCLTDL)
AC_SUBST(LIBLTDL)
AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
AC_CONFIG_SUBDIRS
For a program built using MinGW, and which uses libltdl to load
modules, libltdl attempts to dynamically load the library listed in
the 'old_library' definition if there is nothing listed in the
'dlname' definition. This results in an attempt to load a .a file
(e.g. libiconv.a). The end
of them) from one of the other modules. The module loader
won't load the second module if the first isn't configured, so up until
recently this has been fine.
However, with the removal of LT_GLOBAL from libltdl, the symbols of the
first module (rlm_eap_tls) are no longer directly available
of it I think I have a basic handle on. However, now
| I'm moving into a section of my project which I'd like to use libltdl with.
| On freeBSD, libtool is apparently configured by default to not install
| libltdl. It appears to build it, but not install the libltdl library and
| ltdl.h into /usr
of my project which I'd like to use libltdl with.
On freeBSD, libtool is apparently configured by default to not install
libltdl. It appears to build it, but not install the libltdl library and
ltdl.h into /usr/local/lib and /usr/local/include. Side question - does
anyone know why this is turned off
I'm trying to get FreeRADIUS to run on my BSD/OS machine. I've
found what I think is a bug in the libltdl they ship, and the code
appears the same in libtool 1.5.2's libltdl.
In load_deplibs, it parses the 'deplibs' arg passed to it, and
if there are '-L' or '-R' parameters, it calls
to depend on which dependent program requests the
loading. The error information returned by libltdl doesn't seem to
make any sense since it refers to unresolved symbols from previously
loaded modules. Removing just one problem module from the load
request causes all of the loads to succeed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
| On Wed, 26 Nov 2003, Gary V. Vaughan wrote:
|
|
|Bob Friesenhahn wrote:
|
|The issues I mention are primarily philosophical and religious.
|There is a subversive element of open source society that is willing
|to use Autoconf
the
|necessary for libltdl. Would that it were so simple ;-)
|
|
| Wait a minute, we have such a macro: it's called AM_INIT_AUTOMAKE.
Ah, so we can use AM_INIT_AUTOMAKE even if we don't want to use Automake?
If so, all we need is to add a call to AM_INIT_AUTOMAKE to AC_LIB_LTDL. Hmmm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
| On Tue, 25 Nov 2003, Alexandre Duret-Lutz wrote:
|
|
|On Tue, Nov 25, 2003 at 03:35:25PM +, Gary V. Vaughan wrote:
|
|If so, all we need is to add a call to AM_INIT_AUTOMAKE to
|AC_LIB_LTDL. Hmmm, but then if a
On Wed, 26 Nov 2003, Gary V. Vaughan wrote:
I don't really want to take on the burden of hand maintaining an enormous
generated Makefile.in, when maintaining a tiny Makefile.am and enhancing
automake a little to help with generation is possible.
Why not try adding
Author `(_~)_ http://sources.redhat.com/autobook
Index: ChangeLog
from Gary V. Vaughan [EMAIL PROTECTED]
* libltdl/configure.ac: Removed.
* configure.ac (AC_CONFIG_HEADERS): Merged from
libltdl/configure.ac.
(AC_LIB_LTDL): Ditto.
(AC_CONFIG_FILES): Add libltdl/Makefile.
(AC_CONFIG_SUBDIRS
Bob Friesenhahn [EMAIL PROTECTED] writes:
The issues I mention are primarily philosophical and religious. There
is a subversive element of open source society that is willing to use
Autoconf and Libtool, but not Automake. The FreeType and libJPEG
projects come to mind.
Yup, I'm in that
On Wed, 26 Nov 2003, Gary V. Vaughan wrote:
Bob Friesenhahn wrote:
The issues I mention are primarily philosophical and religious.
There is a subversive element of open source society that is willing
to use Autoconf and Libtool, but not Automake. The FreeType and
libJPEG projects come
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
| On Mon, 24 Nov 2003, Gary V. Vaughan wrote:
|
| There are a number of issues that would have to be handled in order to
| properly integrate libltdl configure/build into the dependent
| package's configure/build. Historically
On Tue, Nov 25, 2003 at 02:31:10PM +, Gary V. Vaughan wrote:
| To support this you need to rewrite Makefile.in without Automake (as
| Gettext does), or let these people AC_CONFIG_SUBDIRS the selfcontained
| libltdl package.
Okay. Since we are trying to get rid of AC_CONFIG_SUBDIRS, we
|| libltdl package.
|
|Okay. Since we are trying to get rid of AC_CONFIG_SUBDIRS, we
|should try and build on gettext's work I think. Maybe we can
|collaborate with Bruno to generalize the rewriting and get it into
|the next automake?
|
|
| I'm afraid I have no idea what you talk about. By rewriting
On Tue, Nov 25, 2003 at 03:07:53PM +, Gary V. Vaughan wrote:
I thought you meant that Bruno had a macro that did AM_INIT_AUTOMAKE-a-like
AC_SUBSTing for gettext's needs, and that another similar macro could do the
necessary for libltdl. Would that it were so simple ;-)
Wait a minute, we
On Tue, 25 Nov 2003, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
| On Mon, 24 Nov 2003, Gary V. Vaughan wrote:
|
| There are a number of issues that would have to be handled in order to
| properly integrate libltdl configure/build
the
|necessary for libltdl. Would that it were so simple ;-)
|
|
| Wait a minute, we have such a macro: it's called AM_INIT_AUTOMAKE.
Ah, so we can use AM_INIT_AUTOMAKE even if we don't want to use Automake?
If so, all we need is to add a call to AM_INIT_AUTOMAKE to AC_LIB_LTDL. Hmmm
sensible to me.
1) You need to have libltdl/Makefile.in regenerated with the
automake version that matches the aclocal version used to rebuild
aclocal.m4
2) automake should only rebuild the Makefile.in which have a matching
Makefile.am. So this is a no-op for the rest of the project
autoreconf, it will run automake -a :-(
|
|
| Running automake in this case sounds sensible to me.
| 1) You need to have libltdl/Makefile.in regenerated with the
| automake version that matches the aclocal version used to rebuild
| aclocal.m4
| 2) automake should only rebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
| It seems to me that for packages which embed libtool and use libltdl,
| it is very trivial for the package's configure script to also
| configure libltdl. This is *much* more efficient time-wise and
| space-wise than
On Mon, 24 Nov 2003, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
| It seems to me that for packages which embed libtool and use libltdl,
| it is very trivial for the package's configure script to also
| configure libltdl. This is *much* more
It seems to me that for packages which embed libtool and use libltdl,
it is very trivial for the package's configure script to also
configure libltdl. This is *much* more efficient time-wise and
space-wise than a recursive configure. The fact that the libtool
package uses a recursive configure
Hi Libtool'ers,
I've written a bug report to [EMAIL PROTECTED], but no one seems to
have noticed. I think at least the second problem is worth
addressing. Please take a look at:
http://mail.gnu.org/archive/html/bug-libtool/2003-01/msg00030.html
Yours,
___ | Christian Holm Christensen
On Mon, Dec 30, 2002 at 04:42:50PM +1100, Conrad Canterford wrote:
This is almost certainly a user error, not a libltdl error, but I cannot
work out how to make this work. I have a .so file which contains my user
interface. The main program finds the path to it and the names of
varioius
Hi,
Guile uses libtldl to do its dynamic linking and we decided to ship
our own copy of it (suitably renamed) since we found that libltdl
contained some showstopper bugs and we wanted be able to fix them
quickly without having to wait for a libtool releases and also to be
sure that people use
I get this error building HEAD and binary-branch.
cd . \
CONFIG_FILES= CONFIG_HEADERS=[config.h:config-h.in] \
/bin/sh ./config.status
config.status: creating [config.h
config.status: error: cannot find input file: config-h.in]
make[1]: *** [stamp-h] Error 1
Stephano == Stephano Mariani [EMAIL PROTECTED] writes:
Stephano libltdl (current from CVS) seems not to return NULL
Stephano when lt_dlopen is passed the name of a non-existent
Stephano file.
I got the same error and sent this patch:
http://mail.gnu.org/pipermail/libtool-patches/2002-March
libltdl (current from CVS) seems not to return NULL when lt_dlopen is
passed the name of a non-existent file. I have used:
void
sk_err ( char *e )
{
fprintf ( stderr, Error: %s\n, e );
exit ( EXIT_FAILURE );
}
int
main ( int argc __attribute ( ( unused ) ),
char *const *argv __attribute
I just looked at rev 1.163 in your CVS repo, and it's definition
of realloc is similarly broken (assuming my analysis below is
correct). Are you aware of this?
I reported this a while ago too -- I sure hope it gets fixed -- it was
causing all manner of problems here. Why does ltdl
I just looked at rev 1.163 in your CVS repo, and it's definition
of realloc is similarly broken (assuming my analysis below is
correct). Are you aware of this?
J
Original Message
Subject: Buffer overruns in kdelibs/libltdl/ltdl.c
Date: Mon, 18 Mar 2002 02:32:23 +
From
]
Subject: libltdl for MinGW32 and native compilers
Dear list,
The attached patch is meant to fix problems with the libltdl.dll
under Windows. It attaches LT_SCOPE to each exported/imported symbol.
Furthermore it changes
#ifdef DLL_EXPORT
# define LT_SCOPE __declspec(dllexport)
#endif
On Tue, 29 Jan 2002, Jon Leichter wrote:
Stefan. I have had the same concerns as you. I have brought up a similar
topic in the past. Even with your patch, DLL_EXPORT is a flawed macro name.
I'd suggest the following patch:
#ifdef LIBLTDL_DLL_IMPORT
# define LT_SCOPE __declspec(dllimport)
Sent: Tuesday, January 29, 2002 10:41 AM
To: Jon Leichter
Cc: [EMAIL PROTECTED]
Subject: RE: libltdl for MinGW32 and native compilers
On Tue, 29 Jan 2002, Jon Leichter wrote:
Stefan. I have had the same concerns as you. I have brought up a similar
topic in the past. Even with your patch
() takes 3rd
argument as size_t, not int. Based on lint run from
Bob Friesenhahn [EMAIL PROTECTED].
On Sun, Sep 30, 2001 at 11:04:35AM -0500, Bob Friesenhahn wrote:
Here is the output from Sun's 64-bit lint tool when run on libltdl
current as of September 29. You will notice
sprintf (filename, %.*s/%s, (int) dirname_len, dirname, dlname);
Given that the rest of ltdl uses strcpy and strcat, I fail to
understand the presence of this sprintf.
___
Libtool mailing list
[EMAIL PROTECTED]
On Sun, 30 Sep 2001 [EMAIL PROTECTED] wrote:
On Sat, Sep 29, 2001 at 10:56:13PM -0500, Bob Friesenhahn wrote:
The problem with libltdl in the Solaris LP64 64-bit model is due to a
mismatch with sizes. argzize_path requires size_t. Under 64-bits
size_t is 8 bytes and int is 4 bytes
On Sat, Sep 29, 2001 at 10:56:13PM -0500, Bob Friesenhahn wrote:
The problem with libltdl in the Solaris LP64 64-bit model is due to a
mismatch with sizes. argzize_path requires size_t. Under 64-bits
size_t is 8 bytes and int is 4 bytes. Here is a patch which should
resolve the problem
In regard to: Re: libltdl 64-bit lint, [EMAIL PROTECTED] said...:
static lt_ptr
realloc (ptr, size)
lt_ptr ptr;
size_t size;
{
if (size = 0)
Is size_t always unsigned?
It is on all the platforms I've seen -- that's why there's an ssize_t
(signed size_t).
sprintf (filename, %.*s
On Sun, Sep 30, 2001 at 11:04:35AM -0500, Bob Friesenhahn wrote:
I don't have ready access to a 64-bit development environment, so I am
passing this lint output on from someone else.
There is an 'unblessed' version of gcc 3.0.1 for sparcv9-sun-solaris2.7 (64bit)
at http://ice.mudshark.org.
Under SPARC Solaris, libltdl crashes when compiled for the 64-bit
addressing model. I received these words from the ImageMagick
developer who is flushing out 64-bit related bugs:
The bug is in ltdl and may be related to 64-bit or perhaps not. I added
(void) lt_dlopen(tiff.la) as the very first
The problem with libltdl in the Solaris LP64 64-bit model is due to a
mismatch with sizes. argzize_path requires size_t. Under 64-bits
size_t is 8 bytes and int is 4 bytes. Here is a patch which should
resolve the problem.
Index: ltdl.c
Hi,
I'm currently porting a program to libtool usage + libltdl.
In my configure.in I have:
...
AC_CONFIG_AUX_DIR(config)
...
AC_LIBLTDL_CONVENIENCE
AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL
...AC_CONFIG_SUBDIRS(libltdl)
...
I've libtoolized the package (libtoolize --force --copy --ltdl), so the
libltdl
Hi,
On Tue, 20 Mar 2001, Gary V. Vaughan wrote:
Nor does libltdl, since lt_dlsym() doesn't really work with the C++ name
mangler. Unfortunately, this means that the dlopen concept doesn't
really port to C++. I can imagine a hairy workaround, but I don't
inflict C++ on myself
On Tuesday 20 March 2001 4:29 am, Tim Janik wrote:
On Tue, 20 Mar 2001, Gary V. Vaughan wrote:
(another implication just sprang to my mind, GModule doesn't currently
handle static C++ constructors
Nor does libltdl, since lt_dlsym() doesn't really work with the C++ name
mangler
When the development version of Autoconf is used to generate a
configure script from CVS libltdl's configure.in this error occurs.
configure.in:36: error: m4_require: circular dependency of AC_LTDL_SYMBOL_USCORE
configure.in:36: AC_LTDL_SYMBOL_USCORE is required by...
./aclocal.m4:3382:
doesn't match the keyword generated by the
libtool script. A patch is included below.
2000-10-20 Utz-Uwe Haus [EMAIL PROTECTED]
* libltdl/ltdl.c (lt_dlopen): Changed "dl_dependency_libs" keyword
to "dependency_libs".
Thanks. I have applied this patch to HEA
doesn't match the keyword generated by the
libtool script. A patch is included below.
There was also a bunch of missing quotes around `test' arguments in
the scripts, which confused /bin/test on Solaris 2.7 boxes.
2000-10-20 Utz-Uwe Haus [EMAIL PROTECTED]
* libltdl/ltdl.c (lt_dlopen
On Dec 14, 2000, Albert Chin-A-Young [EMAIL PROTECTED] wrote:
* libltdl/ltdl.c (lt_dlopen): Changed "dl_dependency_libs" keyword
to "dependency_libs".
Any reason this patch has not been integrated yet?
i) I was too busy to check it in when I received the message
original
That's not a problem, since stat() follows symlinks.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Utz-Uwe
.
2000-10-20 Utz-Uwe Haus [EMAIL PROTECTED]
* libltdl/ltdl.c (lt_dlopen): Changed "dl_dependency_libs" keyword
to "dependency_libs".
Excellent! This has greatly helped with KDE.
Quick question though. Where dependency_libs is large and references
othe
is included below.
There was also a bunch of missing quotes around `test' arguments in
the scripts, which confused /bin/test on Solaris 2.7 boxes.
2000-10-20 Utz-Uwe Haus [EMAIL PROTECTED]
* libltdl/ltdl.c (lt_dlopen): Changed "dl_dependency_libs" keyword
to "
stuff
anyway.
(I have a small user-mode program that can panic the kernel when using AIX
dlopen
on a corrupted shared library. Loading using the native loader doesn't have
this
problem.)
Excellent. Thats why libltdl was designed the way that it was =)O|
Eagerly awaiting your patch!
Cheers
build complete...
Any objections?
I think the right fix is to arrange for all references to shlib_ext to
be enclosed in #ifdef LTDL_SHLIB_EXT/#endif.
Please try this patch:
Index: ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
* libltdl/ltdl.c (load_deplibs): Don't append shlib_ext
Alexandre Oliva wrote:
On Sep 1, 2000, Alexandre Oliva [EMAIL PROTECTED] wrote:
I think the right fix is to arrange for all references to shlib_ext to
be enclosed in #ifdef LTDL_SHLIB_EXT/#endif.
Please try this patch:
[patch deleted.]
Thanks Alexandre! This works for me. I
On Sep 4, 2000, Patrick Tullmann [EMAIL PROTECTED] wrote:
Let me know if you would like me to check patch this into the Kaffe
CVS.
Please go ahead.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com,
On Fri, Jul 28, 2000 at 02:00:15PM -0700, Tom Matelich wrote:
Hello,
I am going to be implementing a plug-in system for a C++
application that needs to run on Linux, HP-UX, and Windows. I see
that libltdl will load shared libraries for each of these platforms
Hello!
The CVS/Head version of libltdl/ltdl.c begins with 'g'
Please be careful and run "make check" before "cvs commit"
Time to setup Tinderbox for Auto* tools?
Regards,
Pavel Roskin
On Apr 12, 2000, Ossama Othman [EMAIL PROTECTED] wrote:
On Wed, Apr 12, 2000 at 07:54:47PM -0400, Kevin Atkinson wrote:
On 11 Apr 2000, Alexandre Oliva wrote:
On Apr 10, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote:
1) On many platforms libtool can create shared libraries for C but
On 13 Apr 2000, Alexandre Oliva wrote:
On Apr 12, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote:
On 12 Apr 2000, Alexandre Oliva wrote:
On Apr 12, 2000, Michael Bletzinger [EMAIL PROTECTED] wrote:
Another option you might to try is listing libstdc++.a as an object
when you are
On Apr 13, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote:
On 13 Apr 2000, Alexandre Oliva wrote:
On Apr 12, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote:
On 12 Apr 2000, Alexandre Oliva wrote:
On Apr 12, 2000, Michael Bletzinger [EMAIL PROTECTED] wrote:
Another option you might to
On Tue, 11 Apr 2000, Ossama Othman wrote:
Hi Kevin,
On Tue, Apr 11, 2000 at 02:43:23AM -0400, Kevin Atkinson wrote:
On Mon, 10 Apr 2000, Ossama Othman wrote:
Right. I don't have access to all of the platforms supported by libtool's
C library support so I wasn't able to
On Apr 11, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote:
You're linking C++ libraries to a C program? That seems a bit odd. Did I
misunderstand you?
Why? I have a library that is written in C++ but I would like C
programs to be able to use my library via extern "C" functions.
What is so
On 11 Apr 2000, Alexandre Oliva wrote:
On Apr 11, 2000, Kevin Atkinson [EMAIL PROTECTED] wrote:
You're linking C++ libraries to a C program? That seems a bit odd. Did I
misunderstand you?
Why? I have a library that is written in C++ but I would like C
programs to be able to use
401 - 477 of 477 matches
Mail list logo
