Re: cygwin build problem with m4 HEAD

[Ralf Wildenhues]

Hi Eric,

* Eric Blake wrote on Fri, Sep 02, 2005 at 03:29:58PM CEST:
 
 I don't know if this is a bug in m4 or in libtool, but with the absolute
 latest CVS autoconf, automake, and libtool installed into /usr/local, and
 latest CVS m4 plus my patch to fix bootstrap
 (http://article.gmane.org/gmane.comp.gnu.m4.patches/229), m4 is failing to
 build on cygwin due to:
 
 /bin/sh ./libtool --tag=CC   --mode=link gcc  -O2 -pipe -no-undefined
 - -export-dynamic  -o m4/libm4.la -rpath /usr/local/lib m4/builtin.lo
 m4/debug.lo m4/hash.lo m4/input.lo m4/m4.lo m4/macro.lo m4/module.lo
 m4/output.lo m4/path.lo m4/symtab.lo m4/syntax.lo m4/utility.lo
 gnu/libgnu.la -lltdl -lintl
 libtool: link: rm -fr  m4/.libs/libm4.dll.a
 libtool: link: gcc -shared  m4/.libs/builtin.o m4/.libs/debug.o
 m4/.libs/hash.o m4/.libs/input.o m4/.libs/m4.o m4/.libs/macro.o
 m4/.libs/module.o m4/.libs/output.o m4/.libs/path.o m4/.libs/symtab.o
 m4/.libs/syntax.o m4/.libs/utility.o  -Wl,--whole-archive
 gnu/.libs/libgnu.a -Wl,--no-whole-archive  /usr/lib/libltdl.dll.a
 /usr/lib/libintl.dll.a -L/usr/lib /usr/lib/libiconv.dll.a -o
 m4/.libs/cygm4-0.dll -Wl,--image-base=0x1000
 - -Wl,--out-implib,m4/.libs/libm4.dll.a
 Creating library file: m4/.libs/libm4.dll.a
 m4/.libs/module.o:module.c:(.text+0x6cb): undefined reference to
 `_lt_dlhandle_find'
 m4/.libs/module.o:module.c:(.text+0x8a5): undefined reference to
 `_lt_dlhandle_first'
 m4/.libs/module.o:module.c:(.text+0x95e): undefined reference to
 `_lt_dlhandle_find'
 m4/.libs/module.o:module.c:(.text+0xea): undefined reference to
 `_lt_dlhandle_first'
 collect2: ld returned 1 exit status
 make[2]: *** [m4/libm4.la] Error 1
 
 I notice that it is attempting to link against /usr/lib/libltdl.dll.a,
 which comes from libtool 1.5.18, rather than /usr/local/lib/libltdl.dll.a,
 which is my installed libtool 2.1a, and I am pretty sure that
 lt_dlhandle_fi{nd,rst} were added in 2.x, explaining the link failure.
 What I can't track down is why the link command is looking in the wrong
 directory, and thus getting the wrong symbols for libltdl.

I believe Gary fixed this issue in Libtool CVS HEAD now.

Surely you will still have to set CPPFLAGS/LDFLAGS if, on your system,
/usr/include resp /usr/lib is searched before the /usr/local
counterpart.  But in case the one found is not new enough, the libtool
macros will decide to use the in-tree copy of both header files and
library now.

Please report back if you are seeing any other issues.  Thanks!

Cheers,
Ralf


___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: darwin: mix up of .dylib and .bundle

[Peter O'Gorman]

Christoph Egger wrote:


Attached.
libgii-debug-experimental.output.gz is the whole subdirectory
as I sent in my last mail with debug info.
libgii-debug-experimental.output2.gz is the failing libtool link
line with debug info.


Doh! In a directory named ggbundle, file -L /path/to/with/ggbundle/in/it | 
grep bundle will return true!


Let me look into a patch, probably testing for 'Mach-O bundle' is better 
than testing for 'bundle'.






| P.S.: How about integrating libtest into libtool's testsuite?
| It might uncover bugs on many other operating systems
| (win32, linux, *bsd, solaris, aix, etc.)

If you send a patch for head, using the new testsuite and fill out the
fsf copyright assignment forms, sure :-).



hmm... I should subscribe an NDA ?



No, it is not an NDA, the FSF requires that it get copyright for all changes 
that are non-trivial. So for something like your test case you'd have to 
complete a copyright assignment.

http://www.gnu.org/software/libtool/contribute.html

Thanks for this report,
Peter



___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: darwin: mix up of .dylib and .bundle

[Christoph Egger]

 Christoph Egger wrote:
  
  Attached.
  libgii-debug-experimental.output.gz is the whole subdirectory
  as I sent in my last mail with debug info.
  libgii-debug-experimental.output2.gz is the failing libtool link
  line with debug info.
 
 Doh! In a directory named ggbundle,
 file -L /path/to/with/ggbundle/in/it | grep bundle will return true!
 
 Let me look into a patch, probably testing for 'Mach-O bundle' is better 
 than testing for 'bundle'.

I've attached a patch, which fixes this bug.
I also added comments (two lines) which explains what it does and why.
libtool no longer needs to worry about any directory names.

Please review and apply.

-- 
Greetings,

Christoph

Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

ltmain.m4sh.diff
Description: Binary data
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool