RE: 1.4.1@solaris8: __eprintf undefined
Hello Hubert, libtool seems not to link in libgcc.a when using gcc (where this symbol is defined). You may use Sun's native compiler cc to get it working. -- Andreas > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Hubert Feyrer > Sent: Monday, September 10, 2001 3:52 PM > To: [EMAIL PROTECTED] > Subject: 1.4.1@solaris8: __eprintf undefined > > > > Hi! > > I have a problem compiling libtool-1.4.1 on Solaris 8/sparc. When > building, I get an undefined symbol: > > /bin/sh ./libtool --mode=link gcc -g -O2 -o libltdl.la -rpath > /soft/libtool-1.4.1/lib -no-undefined -version-info 3:0:0 > ltdl.lo -ldl > rm -fr .libs/libltdl.la .libs/libltdl.* .libs/libltdl.* > /usr/ccs/bin/ld -G -z defs -h libltdl.so.3 -o .libs/libltdl.so.3.0.0 > ltdl.lo -ldl -lc > Undefined first referenced > symbol in file > __eprintf ltdl.lo > ld: fatal: Symbol referencing errors. No output written to > .libs/libltdl.so.3.0.0 > > > Can anyone tell me how to get libtool going on Solaris 8? > > > - Hubert > > -- > Want to get a clue on IPv6 but don't know where to start? Try this: > * Basics -> > http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html > * Setup -> > http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html > Of course with your #1 IPv6 ready operating system -> http://www.NetBSD.org/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: 1.4.1@solaris8: __eprintf undefined
On Mon, 10 Sep 2001, Andreas Wendt wrote: > libtool seems not to link in libgcc.a when using gcc (where this symbol is > defined). > You may use Sun's native compiler cc to get it working. That's not an option, as the Sun 'cc' costs $. I'll play with -lgcc and see what happens, but it would be really nice if a platform like Solaris would work out of the box. - Hubert -- Want to get a clue on IPv6 but don't know where to start? Try this: * Basics -> http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html * Setup -> http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html Of course with your #1 IPv6 ready operating system -> http://www.NetBSD.org/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
ltdl/mdemo test
I mumbled about mdemo-exec and friends failing a while back, but hopefully
this will make the problem a bit clearer:
Just adding the following to source of 6 September 14:36 GMT:
Index: ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.154
diff -u -r1.154 ltdl.c
--- ltdl.c 2001/09/03 00:22:13 1.154
+++ ltdl.c 2001/09/10 17:25:40
@@ -1567,6 +1567,7 @@
while (syms->name)
{
+printf("filename=%s syms->name=%s\n",filename,syms->name);
if (!syms->address && strcmp(syms->name, filename) == 0)
{
module = (lt_module) syms;
gives (after suitable othe mdemo tests were ran)
% gmake VERBOSE=1 TESTS=mdemo-exec.test check
...
=== Running mdemo-exec.test
Executing uninstalled programs in ../mdemo
Welcome to GNU libtool mdemo!
filename=foo1.a syms->name=foo1.a
module name: foo1
module filename: foo1.a
module reference count: 1
** This is foolib 1 **
hello returned: 57616
hello is ok!
cos (0.0) = 1
sub() called
foo1 is ok!
filename=libfoo2.a syms->name=foo1.a
filename=libfoo2.a syms->name=_foo1_helper
filename=libfoo2.a syms->name=foo1_LTX_foo1
filename=libfoo2.a syms->name=foo1_LTX_hello
filename=libfoo2.a syms->name=foo1_LTX_nothing
filename=libfoo2.a syms->name=libsub.a
filename=libfoo2.a syms->name=sub
filename=libfoo2.a syms->name=libfoo2.a
module name: libfoo2
module filename: libfoo2.a
module reference count: 1
** This is foolib 2 **
hello returned: 57616
hello is ok!
sin (0.0) = 0
sub() called
foo2 is ok!
filename=@PROGRAM@ syms->name=foo1.a
filename=@PROGRAM@ syms->name=_foo1_helper
filename=@PROGRAM@ syms->name=foo1_LTX_foo1
filename=@PROGRAM@ syms->name=foo1_LTX_hello
filename=@PROGRAM@ syms->name=foo1_LTX_nothing
filename=@PROGRAM@ syms->name=libsub.a
filename=@PROGRAM@ syms->name=sub
filename=@PROGRAM@ syms->name=libfoo2.a
filename=@PROGRAM@ syms->name=_foo2_helper
filename=@PROGRAM@ syms->name=libfoo2_LTX_foo2
filename=@PROGRAM@ syms->name=libfoo2_LTX_hello
filename=@PROGRAM@ syms->name=libfoo2_LTX_nothing
filename=@PROGRAM@ syms->name=libsub.a
filename=@PROGRAM@ syms->name=sub
can't dlopen the program!
error was: file not found
./mdemo-exec.test: execution of ../mdemo/mdemo.static failed
Welcome to GNU libtool mdemo!
can't open the module ../mdemo/foo1.la!
error was: file not found
can't open the module ../mdemo/libfoo2.la!
error was: file not found
can't dlopen the program!
error was: file not found
./mdemo-exec.test: execution of ../mdemo/mdemo failed
FAIL: mdemo-exec.test
===
1 of 1 tests failed
===
which I think is from test_dlself() -> lt_dlopen(0) (as opposed to
lt_dlopen(filename) ) -> try_dlopen(&handle,0) -> tryall_dlopen(&newhandle,0)
and so on..
Hope this is clearer,
Cheers,
Patrick
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c and 1.4.1 (type conflicts)
On Sat, Sep 08, 2001 at 01:49:35AM -0700, Bruce Korb wrote:
> Robert Collins wrote:
> >
> > On Sat, 2001-09-08 at 13:31, Gary V. Vaughan wrote:
> > > On Fri, Sep 07, 2001 at 02:45:11PM -0500, Tim Mooney wrote:
> > > Phew! Thanks for that info.
> > >
> > > I'm open to suggestions for a cleaner way to implement this, but I
> > > think that it is an unavoidable weakness in C that forces one to (ab)use
> > > void* in cases such as this.
> >
> > I haven't checked the code in question, but if what youa re doing is
> > returning a pointer to a function froma function, then typdef'ing a
> > function pointer type and returning that should be a clean solution.
> >
> > ie if the function type being passed around is
> > int func(char *, int)
> >
> > typedef int functype(char *, int);
> >
> > functype *
> > functionthatreturnspointertofunction()
> > {
> > ...
> > }
>
> That's my preferred solution, too. Unfortunately, libtool is _still_
> trying to be K&R compatible, and ancient K&R won't let you typedef
> procedures.
I didn't know that... pfff. :-P
Anyway, would that it were so easy. foreach_dirinpath is a general
helper function used in all sorts of contexts throughout ltdl.c:
typedef int foreach_callback_func LT_PARAMS((char *filename, lt_ptr data1,
lt_ptr data2));
static int
foreach_dirinpath (search_path, base_name, func, data1, data2)
const char *search_path;
const char *base_name;
foreach_callback_func *func;
lt_ptr data1;
lt_ptr data2;
{
...
}
This is an API call, implemented over foreach_dirinpath:
int
lt_dlforeachfile (search_path, func, data)
const char *search_path;
int (*func) LT_PARAMS ((const char *filename, lt_ptr data));
lt_ptr data;
{
...
if (search_path)
{
/* If a specific path was passed, search only the directories
listed in it. */
is_done = foreach_dirinpath (search_path, 0,
foreachfile_callback, func, data);
}
...
}
This function has to match the foreach_callback_func footprint, so
that it can be passed to foreach_dirinpath, but it also needs to accept
a function pointer itself to work with lt_dlforeachfile:
static int
foreachfile_callback (dirname, data1, data2)
char *dirname;
lt_ptr data1;
lt_ptr data2;
{
int (*func) LT_PARAMS((const char *filename, lt_ptr data))
= (int (*) LT_PARAMS((const char *filename, lt_ptr data))) data1;
^^ Here is one of the casts xlc dislikes ^
...
{
char *filename = 0;
while ((filename = argz_next (argz, argz_len, filename)))
if ((is_done = (*func) (filename, data2)))
break;
} }
...
}
Suggestions?
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl/mdemo test
On Monday 10 September 2001 18:59, Patrick Welche wrote: > I mumbled about mdemo-exec and friends failing a while back, but hopefully > this will make the problem a bit clearer: I already stated that the problem lies in the fact that the configuration goop expects dlopen to be in a library other than libc for libltdl. This is plain wrong on NetBSD and probably other BSD derivatives. Nick ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool broken in kdebase 2.2.0
On Sat, Sep 08, 2001 at 04:34:07PM -0400, Jack Howarth wrote: > Hello, >I have noticed that on debian ppc sid we > have problems building kdebase 2.2.0 because > of flaws in the libtool included there. The > problem is that the libtool is linking with > --nostdlib but fails to pass -lgcc along for > the link. This results in shared libs with > an undefined symbol for __cmpdi2 which would > be resolved by linking in libgcc. I would like > to here some suggestions on how to address this > by a patch to libtool so we don't have to hack > the Makefile.am's in kdebase. I have been told > that libtool should be smart enough to figure > out from gcc -v that it needs to link in libgcc. > Thanks in advance for any help in resolving this > issue. > Jack Howarth I think we have uncovered a serious flaw in the link strategy employed by libtool. I can see the problem, but I don;t understand the details... you will need to explain exactly what is going wrong to me, so that we can hopefully figure out how to fix it. For instance, is it always the case that whatever file is listed in the *libgcc section of the spec file should be manually linked in by libtool, if it has decided (for whatever reason) to pass --nostdlib on the link line? Even for g++, gcj? What happens when linking a library... linking libgcc.a into a shared library is asking for trouble. I wish I had a better understanding of linkers and the like :-( Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.4.1@solaris8: __eprintf undefined
On Mon, Sep 10, 2001 at 05:55:57PM +0200, Hubert Feyrer wrote: > On Mon, 10 Sep 2001, Andreas Wendt wrote: > > libtool seems not to link in libgcc.a when using gcc (where this symbol is > > defined). > > You may use Sun's native compiler cc to get it working. > > That's not an option, as the Sun 'cc' costs $. It is a long standing bug with gcc using native ld on solaris, revealed in this release because I have started using assert() in ltdl.c (which requires __eprintf from libgcc.a). Here are a couple of options: * upgrade to gcc 3.0.1 from sunfreeware.com which doesn't have the bug * recompile gcc-2.95.x to use binutils rather than native ld I'm about to release 1.4.2, which will diagnose the bug if you have a setup that is susceptible, but will still link for you (with a warning) until you have time to upgrade... > I'll play with -lgcc and see what happens, but it would be really nice if > a platform like Solaris would work out of the box. I know. :-( Sorry about that. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4.1 tests
On Sun, Sep 09, 2001 at 06:05:56PM +0100, s_a_white wrote: > I've performed the following tests with the following results: Cool! Thanks. > Now running configure detects the executable extension as none. Performing > a make builds the program but the link fails stating that log10 is an > unresolved symbol. Under 1.3.5 the code built fine, so am I supposed to > hardcoding -lm now? Nope. That would be a bug :-( > I now re-run the configure and it now detects the executable > extension as .C ... ! I now build the code and it compiles fine so the > maths library is already included. !! Do you know why that happens? > I thought 1.4 was integrated with the multi-language branch and that had > better support for c++? Nope. I merged the multi-language branch into the trunk after 1.4 was released. 1.4b has the merged code, but there are still several warts. > As for the extension detecting correctly I first > reported this with libtool 1.3C. libtool 1.3b had no problems and returned > the extension correctly. 1.3b had its own code to detect EXEEXT, but this code was migrated to autoconf and improved. You might get further if you upgrade to a newer autoconf... but 1.4 is still lacking multi-language support. > I also hoped to update to 1.4 because I've had > problems from some users by using libtool 1.3B and just hardcoding -lstdc++ > on the link line. 1.4 won't help much there I'm afraid... though it does fix many bugs from 1.3b. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Linking non libtool libraries with libtool generated libraries
This looks like a 1.3.x error message. Upgrade to 1.4.2 and try again? Cheers, Gary. On Mon, Sep 10, 2001 at 01:14:45PM +0100, Larry Cotton wrote: > > I wrote on Friday : > > > > Hi > > I'm completely new to libtool, Autoconf, Automake et., but I have recently > down load and biilt php whose build system uses these tools. > > I have also built an php extenstion which I wish to build in to php. > > My problem is that my extension depends on external libraries which have not > been built using libtool. When I try to link them into the php exe i get an > error message something like : > cannot build libtool library from non-libtool objects: > ext/phpwebinterface/libprodssinterface.a > > So I built my external libraries using libtool and copied them accross to my > extension directory with commands similar to : > libtool: link: libtool --mode=compile g++ -c $INCLUDES file.cxx > > libtool --mode=link g++ -static -o libwebprodssinterface.la *.lo > ranlib .libs/libwebprodssinterface.a > chmod 644 .libs/libwebprodssinterface.a > cp .libs/libwebprodssinterface.la $PHP_EXT/phpwebinterface/.libs > cp .libs/libwebprodssinterface.a $PHP_EXT/phpwebinterface/.libs > > but I still get the same error : > libtool: link: 'ext/phpwebinterface/libprodssinterface.la' is not a valid > libtool archive > > or if I link to the library directly : > cannot build libtool library from non-libtool objects: > ext/phpwebinterface/libprodssinterface.a > > Could anyone give me an idea how I can either get my external libraries to > be conpatible or modify the php libtool build stuff to link to standard > object files ? > > Cheers > Larry > > > > > Anyone know anything about this ? > > Cheers > Larry > > > > Imerge Limited Tel :- +44 (0)1954 783600 > Unit 6 Bar Hill Business Park Fax :- +44 (0)1954 783601 > Saxon Way Web :- http://www.imerge.co.uk > Bar Hill > Cambridge > CB3 8SL > United Kingdom > > > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool broken in kdebase 2.2.0
On Mon, Sep 10, 2001 at 09:46:15PM +0100, Gary V. Vaughan wrote: > I wish I had a better understanding of linkers and the like :-( Title: Linkers and Loaders ISBN: 1558604960 Author: John R. Levine Date: 1999 -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.4.1@solaris8: __eprintf undefined
On Mon, 10 Sep 2001, Gary V. Vaughan wrote: > It is a long standing bug with gcc using native ld on solaris, > revealed in this release because I have started using assert() in > ltdl.c (which requires __eprintf from libgcc.a). > > Here are a couple of options: > > * upgrade to gcc 3.0.1 from sunfreeware.com which doesn't have the bug > * recompile gcc-2.95.x to use binutils rather than native ld Um, I wasted some time on gcc 3.x, and decided to stay at 2.95.3 for now. I'm running the following lines after running configure, and libtool works fine now: sed \ '/^LIBADD_DL/s,$,-L/soft/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -lgcc,' libltdl/Makefile >libltdl/Makefile.fixed mv libltdl/Makefile.fixed libltdl/Makefile Thanks for that tip! :-) Now to teach zlib to use libtool next... > I'm about to release 1.4.2, which will diagnose the bug if you have a > setup that is susceptible, but will still link for you (with a > warning) until you have time to upgrade... cool, thanks for that in advance! Let me add a work of thanks for all the libtool developers for providing a nice tool that gives a uniform interface to shlib creation on many platforms. (I use libtool in the NetBSD packages collection which works on quite a number of a.out and ELF platforms, besides Solaris ;-) - Hubert -- Want to get a clue on IPv6 but don't know where to start? Try this: * Basics -> http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html * Setup -> http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html Of course with your #1 IPv6 ready operating system -> http://www.NetBSD.org/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
lib installation
Hi, I'm trying to setup a process where when I run a make for any given library, it should build the .a or .so and install it. Instead of doing a make install after the build has taken place. Is there a way to do this? My dilema, is that developers are trying to populate a lib directory with all of the libraries, so that they can use the -L flag and resolve their links. They would like for this to happen when they do a build. So once their Makefiles are created using autoconf and automake. They should be able to execute a make, the make would start building libraries and subsequently install them, in a lib directory, their applications would contain the -L flag to satisfy the symbols. I tried selling the idea of library dependency via libtool, and although they think it is a great concept they still like to populate a lib directory with libraries during the make. Is this possible? Thanks, fausto.. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.4.1@solaris8: __eprintf undefined
On Tue, Sep 11, 2001 at 12:26:44AM +0200, Hubert Feyrer wrote: > On Mon, 10 Sep 2001, Gary V. Vaughan wrote: > > It is a long standing bug with gcc using native ld on solaris, > > revealed in this release because I have started using assert() in > > ltdl.c (which requires __eprintf from libgcc.a). > > > > Here are a couple of options: > > > > * upgrade to gcc 3.0.1 from sunfreeware.com which doesn't have the bug > > * recompile gcc-2.95.x to use binutils rather than native ld > > Um, I wasted some time on gcc 3.x, and decided to stay at 2.95.3 for now. > I'm running the following lines after running configure, and libtool > works fine now: > > sed \ > '/^LIBADD_DL/s,$,-L/soft/gcc-2.95.3/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 >-lgcc,' > libltdl/Makefile >libltdl/Makefile.fixed > mv libltdl/Makefile.fixed libltdl/Makefile Using `$CC --print-libgcc-file-name` would be more portable. > Thanks for that tip! :-) > Now to teach zlib to use libtool next... Watch out for zfstream with libtool < 1.4b. It doesn't work (due to broke C++ linking from non-multi-language libtool). > > I'm about to release 1.4.2, which will diagnose the bug if you have a > > setup that is susceptible, but will still link for you (with a > > warning) until you have time to upgrade... > > cool, thanks for that in advance! No probs. Any minute now > Let me add a work of thanks for all the libtool developers for providing a > nice tool that gives a uniform interface to shlib creation on many > platforms. (I use libtool in the NetBSD packages collection which works on > quite a number of a.out and ELF platforms, besides Solaris ;-) Much appreciated (from all of us). Libtool is a peculiar project in that it is driven mainly by patches from users with access to many platforms we would not individually have time to maintain. So thanks to you guys for keeping the fixes rolling in :-) Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c and 1.4.1 (type conflicts)
"Gary V. Vaughan" wrote: > Suggestions? 1. Demand an ANSI compiler or better. Anyone still working with anything older is a hobbiest and can go grab GCC 2.7.1 and bootstrap. No sympathy from me. 2. Recast everything as "ptr_t" which is a typedef for "char*". Amdhal is the only system I know of with 64 bit proc pointers and 32 bit data pointers. If you gotta support Amdhal, then kludge some sort of hack for that weirdo platform. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c and 1.4.1 (type conflicts)
On Mon, Sep 10, 2001 at 11:29:57AM -0700, Bruce Korb wrote: > "Gary V. Vaughan" wrote: > > > Suggestions? > > 2. Recast everything as "ptr_t" which is a typedef for "char*". > Amdhal is the only system I know of with 64 bit proc pointers > and 32 bit data pointers. If you gotta support Amdhal, then > kludge some sort of hack for that weirdo platform. This is what I am doing already. Isn't it? (Not the Amdhal bit) Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[ 100049 ] conveniece libraries under darwin?
Support Request #100049, was updated on 2001-May-30 05:53 You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=100049&group_id=25 Category: None Status: Open Priority: 3 Summary: conveniece libraries under darwin? By: gary Date: 2001-Sep-11 03:01 Message: Logged In: YES user_id=121 Browser: Mozilla/4.74 [en] (X11; U; Linux 2.2.16 i686) Both of these patches cause the cdemo tests to FAILin their respective branches, so I cannot apply them. -- By: chrisp Date: 2001-Sep-09 21:21 Message: Logged In: YES user_id=1955 Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90) I've posted cleaned-up versions of the patch for HEAD and branch-1-4 in the patch tracker, item #31 and #32. Explanations are attached to #31. Errr.. were attached.. were lost by the site... Okay, I'll try to recall what I wrote. The problem is that convenience libraries are added to both $convenience and $deplibs. That causes the library to be listed twice on the final link command line. That's a problem on platforms with pedantic linkers like Darwin, which complain about duplicate symbols as a result. Note that at the core this actually affects all platforms, not just Darwin. (There may be some that rely on the current errenous behaviour, though. whole_archive_flag_spec=' ' *cough*) Hope this helps, -chrisp -- You can respond by visiting: http://savannah.gnu.org/support/?func=detailsupport&support_id=100049&group_id=25 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Does libtool know how to deal with libgcc.a%s?
On Fri, Sep 07, 2001 at 09:27:33PM -0700, H . J . Lu wrote: > On Fri, Sep 07, 2001 at 09:19:08PM -0700, H . J . Lu wrote: > > On Sat, Sep 08, 2001 at 12:14:49AM -0400, Jack Howarth wrote: > > > howarth@bogus:~$ gcc -v > > > Reading specs from /usr/lib/gcc-lib/powerpc-linux/2.95.4/specs > > > gcc version 2.95.4 20010902 (Debian prerelease) > > > > > > *libgcc: > > > libgcc.a%s > > > > > > > It looks like gcc is ok and libtool is broken. Please try to change to > > > > *libgcc: > > -lgcc > > > > in /usr/lib/gcc-lib/powerpc-linux/2.95.4/specs. libtool may not know > > how to deal with libgcc.a%s. On the other hand, I don't know why ppc > > uses `libgcc.a%s' instead of `-lgcc' to begin with. > > > > Gcc on some platforms uses `libgcc.a%s' instead of `-lgcc'. Does > libtool know how to deal with libgcc.a%s? It seems that libtool > drops `libgcc.a%s' for the linking. It doesn't really know about either, it doesn't look at spec files at all. Libtool does nothing more than link with $CC when it is know to work, or else $LD if it proves to be necessary. The one wrinkle in this formula is that when CC=gcc, libtool will try a dummy link to determine whether `-lc' is implicitly added when the link phase is handled by gcc. It seems as though libtool needs to do more. Unfortunately my knowledge of linkers and loaders is superficial, so you will need to explain what it is that libtool is (or isn't) doing, and what you would have expected libtool to do (or not do) in painstaking detail in order for me to get a good grasp of what I can do to fix it :-( Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lib installation
Fausto Sanchez writes: > I'm trying to setup a process where when I run a make for any given library, it > should build the .a or .so and install it. Instead of doing a make install > after the > build has taken place. Is there a way to do this? alias make='make install' Incidentally, this has nothing to do with libtool, because libtool doesn't have anything to do with makefiles. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
ANNOUNCE: Libtool 1.4.2 released from stable branch
I am pleased to announce the release of GNU Libtool 1.4.2, which now builds correctly on Solaris again and diagnoses problematic combinations of gcc and native ld. There are also a small number of incremental improvements and bugfixes since the last release. This release was bootstrapped and tested with Automake 1.4-p5 and Autoconf 2.13, but can be used in conjunction with any newer release or either of these in your own projects. Tarballs and both traditional and xdelta diffs against release 1.4.1 are available now from ftp.gnu.org, and will soon arrive on all gnu mirrors: ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.2.tar.gz(1160k) ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.1-1.4.2.diff.gz ( 16k) ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.1-1.4.2.tar.xdp.gz ( 32k) Or you can fetch the release from anonymous cvs with the tag `release-1-4-2' by following the instructions at: http://www.gnu.org/software/libtool MD5 signatures for these files are as follows: 95dd3de3b249fe1199ed60ed8e46f60c libtool-1.4.2.tar.gz 8e42fd53e0edb5fc3e03accef836fa2d libtool-1.4.1-1.4.2.diff.gz 74b99a29bee28c5cf60dddee6d632284 libtool-1.4.1-1.4.2.tar.xdp.gz NEWS - list of user-visible changes between releases of GNU Libtool New in 1.4.2: 2001-09-11; CVS version 1.4.1a, Gary V. Vaughan: * libltdl now builds on solaris again * diagnose and warn about not-quite-working combinations of gcc and ld on solaris * Improved OpenBSD support. * Improved cygwin support. * Bugfixes. Download, compile, install, send a bug report to [EMAIL PROTECTED] you know the drill ;-) Enjoy! Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
