libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

debugging the cygwin issues I'm having


From: Robert Collins
Subject: debugging the cygwin issues I'm having
Date: Tue, 5 Jun 2001 22:47:36 +1000

I'm stepping thru the failing tests. A number were automake-HEAD related
as I've mentioned already(*see the end for a refresher)

The current one I'm beating my head against is demo-make after
demo-shared.

Problem summary: libtool is having trouble with the .lo files.

It's finding nothing in the non_pic_object line, and then giving up on
linking in that object. It's not attempting to build a non_pic object
either, which is kind of strange :-[.

It links ok if I copy the pic object entry to the non_pic line in foo.lo
and hello.lo.

I'm not quite sure whether libtool is expected to rebuild/convert the
pic to a non-pic or what in this situation. Not that demo has been
configured with --disable-static, but isn't passing --no-undefined to
libtool...

so I suspect the core problem is that libtool isn't able to make a
dynamic version of this program, but has been configured to only make
dynamic versions?

Thoughts?

I'm going to get this building a dynamic version in the meantime...
Rob


related output:
==make output showing the problem==
mkdir .libs
gcc -DPACKAGE=\"hell\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_STRING_
H=1 -DHAVE_MATH_H=
1 -I. -I/usr/src/libtool/tests/../demo -g -O2 -c
/usr/src/libtool/tests/../demo/hello.c -D
DLL_EXPORT -o .libs/hello.o
/bin/sh ./libtool --mode=compile
gcc -DPACKAGE=\"hell\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1
 -DHAVE_STRING_H=1 -DHAVE_MATH_H=1  -I. -I/usr/src/libtool/tests/../demo
     -g -O2 -c -o
foo.lo `test -f /usr/src/libtool/tests/../demo/foo.c || echo
'/usr/src/libtool/tests/../de
mo/'`/usr/src/libtool/tests/../demo/foo.c
gcc -DPACKAGE=\"hell\" -DVERSION=\"1.0\" -DHAVE_DLFCN_H=1 -DHAVE_STRING_
H=1 -DHAVE_MATH_H=
1 -I. -I/usr/src/libtool/tests/../demo -g -O2 -c
/usr/src/libtool/tests/../demo/foo.c -DDL
L_EXPORT -o .libs/foo.o
/bin/sh ./libtool --mode=link gcc  -g -O2   -o libhello.la -rpath
/usr/src/libtool/build/t
ests/_inst/lib -version-info 3:12:1 hello.lo foo.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
ar cru .libs/libhello.a
ranlib .libs/libhello.a

==bad hello.lo==
# hello.lo - a libtool object file
# Generated by ltmain.sh - GNU libtool 1.4 (1.927 2001/05/30 19:52:43)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# Name of the PIC object.
pic_object='.libs/hello.o'

# Name of the non-PIC object.
non_pic_object=none


* automake-HEAD seems to consider foo.static to already have an
extension, and rather than creating

foo.static$(EXEEXT): when bin_PROGRAMS=foo.static, it creates foo.static
rules.

I've taken the simple route, of changing foo.static to foo_static in the
libtool Makefile.am's for now as I don't know whether the automake folk
consider that a bug or a feature :-].

I referred to this briefly in a cross-posted email to the automake list,
and hopefully they'll pick that up. If not, I'll come back to it later,
when the mysterious bugs are ironed out.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]