RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to
> what libtool-2.0 will be. Please evaluate.
>
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool! Be sure to revert back to
> "regular" libtool-devel ("1.5.10-1") before packaging any of your
> "stuff" for official releases.
>
> This version passes ALL existing libtool selftests on cygwin, for the
> first time ever.
I have one problem with libtool 1.9d, that I suspect is still present
in 1.9f. If I specify -lpthread when linking, libtool searches for a
real file matching -lpthread, like this:
*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpthread and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libpthread.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
Now, I *know* that I don't need to specify -lpthread. But I would like
libtool to not search for the real file in this case, just as it does
not search for a real file if I specify -lc or -lm.
Because of this, libtool fails to build the dll in question, which is a
pity.
Cheers,
Peter
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Peter Ekberg schrieb:
I have one problem with libtool 1.9d, that I suspect is still present
in 1.9f. If I specify -lpthread when linking, libtool searches for a
real file matching -lpthread, like this:
*** Warning: linker path does not have real file for library -lpthread.
*** I have the capability to make that library automatically link in
when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpthread and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libpthread.a
Then you have a binutils problem. The new magic for /lib/libpthread.a
tells libtool that this is the import library. (which normally would be
called libpthread.dll.a)
$ file -L /lib/libpthread.a
/lib/libpthread.a: current ar archive
# ok, this failed.
$ objdump -f /lib/libpthread.a | sed 10q
#this will detect together with nm that it is an import lib
func_win32_libid () {
win32_libid_type="unknown"
win32_fileres=`file -L $1 2>/dev/null`
case $win32_fileres in
*ar\ archive\ import\ library*) # definitely import
win32_libid_type="x86 archive import"
;;
*ar\ archive*) # could be an import, or static
if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | \
$EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null
; then
win32_nmres=`eval $NM -f posix -A $1 | \
sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'`
if test "X$win32_nmres" = "Ximport" ; then
win32_libid_type="x86 archive import"
else
win32_libid_type="x86 archive static"
fi
fi
;;
Because of this, libtool fails to build the dll in question, which is a
pity.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Reini Urban wrote: > Peter Ekberg schrieb: >> I have one problem with libtool 1.9d, that I suspect is still present >> in 1.9f. If I specify -lpthread when linking, libtool searches for a >> real file matching -lpthread, like this: >> >> *** Warning: linker path does not have real file for library >> -lpthread. >> *** I have the capability to make that library automatically link in >> when >> *** you link to this library. But I can only do this if you have a >> *** shared version of the library, which you do not appear to have >> *** because I did check the linker path looking for a file starting >> *** with libpthread and none of the candidates passed a file format >> test >> *** using a file magic. Last file checked: /lib/libpthread.a > > Then you have a binutils problem. The new magic for /lib/libpthread.a > tells libtool that this is the import library. (which normally would be > called libpthread.dll.a) Actually I don't think I have problems with binutils, but thanks for the useful pointer. I have this in the generated libtool script: --8< # Method to check whether dependent libraries are shared objects. deplibs_check_method="file_magic ^x86 archive import|^x86 DLL" # Command to use when deplibs_check_method == "file_magic". file_magic_cmd="func_win32_libid" --8< Is that what is expected? If I change to deplibs_check_method="file_magic" it works. Any suggestions? Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Peter wrote: > Reini Urban wrote: >> Peter Ekberg schrieb: >>> I have one problem with libtool 1.9d, that I suspect is still present >>> in 1.9f. If I specify -lpthread when linking, libtool searches for a [...] > I have this in the generated libtool script: > --8< > # Method to check whether dependent libraries are shared objects. > deplibs_check_method="file_magic ^x86 archive import|^x86 DLL" > # Command to use when deplibs_check_method == "file_magic". > file_magic_cmd="func_win32_libid" > --8< > Is that what is expected? > If I change to > deplibs_check_method="file_magic" > it works. > Any suggestions? libpthread should be in the list of libraries where these tests are skipped, like it is for libstdc++ or libgcc and others, if it is not included, try the snapshot Charles provided which includes probably some more cygwin related fixes than f-d = 2 versions before the current snapshot, and if this fails too, then please come back. Gerrit -- =^..^= http://nyckelpiga.de/donate.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Peter Ekberg schrieb: Reini Urban wrote: Peter Ekberg schrieb: I have one problem with libtool 1.9d, that I suspect is still present in 1.9f. If I specify -lpthread when linking, libtool searches for a real file matching -lpthread, like this: *** Warning: linker path does not have real file for library -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpthread and none of the candidates passed a file format test *** using a file magic. Last file checked: /lib/libpthread.a Then you have a binutils problem. The new magic for /lib/libpthread.a tells libtool that this is the import library. (which normally would be called libpthread.dll.a) Actually I don't think I have problems with binutils, but thanks for the useful pointer. I think you do have. up-to-date? I have this in the generated libtool script: --8< # Method to check whether dependent libraries are shared objects. deplibs_check_method="file_magic ^x86 archive import|^x86 DLL" # Command to use when deplibs_check_method == "file_magic". file_magic_cmd="func_win32_libid" --8< Is that what is expected? yes, I posted the relevant snippet of this func_win32_libid function, so that you can check what's going on with your objdump and nm on your libpthread.a But you have a different/unsupported build so you should really step through your relevant func_win32_libid() function. If I change to deplibs_check_method="file_magic" it works. because it overrides the check. it passes no args to the func. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Reini Urban wrote: > Peter Ekberg schrieb: >> Reini Urban wrote: >>> Peter Ekberg schrieb: >>> I have one problem with libtool 1.9d, that I suspect is still present in 1.9f. If I specify -lpthread when linking, libtool searches for a real file matching -lpthread, like this: *** Warning: linker path does not have real file for library -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpthread and none of the candidates passed a file format test *** using a file magic. Last file checked: /lib/libpthread.a >>> >>> Then you have a binutils problem. The new magic for >>> /lib/libpthread.a tells libtool that this is the import library. >>> (which normally would be called libpthread.dll.a) >> >> >> Actually I don't think I have problems with binutils, but thanks for >> the useful pointer. > > I think you do have. up-to-date? Yes. >> I have this in the generated libtool script: >> --8< >> # Method to check whether dependent libraries are shared objects. >> deplibs_check_method="file_magic ^x86 archive import|^x86 DLL" >> >> # Command to use when deplibs_check_method == "file_magic". >> file_magic_cmd="func_win32_libid" >> --8< >> >> Is that what is expected? > > yes, I posted the relevant snippet of this func_win32_libid function, > so that you can check what's going on with your objdump and nm on > your libpthread.a But you have a different/unsupported build so you > should really step through your relevant func_win32_libid() function. Ok, I pinpointed the problem. It wasn't a problem with binutils but rather with configure.in. After a recent run of autoupdate it contained: _LT_SET_OPTION([disable-static]) _LT_SET_OPTION([dlopen]) _LT_SET_OPTION([win32-dll]) LT_INIT (with some other stuff in between) Changing that to LT_INIT([disable-static dlopen win32-dll]) fixes the problem which was that $OBJDUMP was empty. AC_CHECK_TOOL(OBJDUMP, objdump, false), among other things, wasn't expanded without the above change in configure.in. Thanks for the help, and sorry for the confusion. (But I still think I have a point in that libtool should drop -lpthread just as it drops -lc and -lm. Why doesn't libtool drop -lpthread?) Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to
> what libtool-2.0 will be. Please evaluate.
>
> NOTE: cygwin maintainers: do NOT release any updates of your packages
> built using this version of libtool! Be sure to revert back to
> "regular" libtool-devel ("1.5.10-1") before packaging any of your
> "stuff" for official releases.
>
> This version passes ALL existing libtool selftests on cygwin, for the
> first time ever.
I have a problem with "make install" of a built executable.
Its wrapper script contains:
---8<
relink_command=""
# This environment variable determines our operation mode.
if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
# install mode needs the following variable:
notinst_deplibs=''
else
---8<
and make install fails with:
libtool: install: invalid libtool wrapper script `xsendbut'
This is because this test is true in ltmain.m4sh:
---8<
# Check the variables that should have been set.
test -z "$notinst_deplibs" && \
func_fatal_error "invalid libtool wrapper script
\`$wrapper'"
---8<
Adding a space between the '' in the wrapper script makes it
work, of course.
It should be noted that this was with libtool-cvs rather
shortly before 1.9f hit the street, so it was not with the
exact version you refer to here. Very close though, and I
see no changes that should affect this behaviour.
Cheers,
Peter
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote: > New alpha versions of libtool available for test. This is > very close to what libtool-2.0 will be. Please evaluate. I have further problems in that linking against -ldxguid prevents a library from being linked as a dll. I only get a static lib, which is not what I want. I realize that /lib/w32api/libdxguid.a is not an import library, but I have no problems with the generated dll if I disable the test that prevent libtool from linking the dll. Is this to be expected? If so, is there a recommended way to work around it? Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Gerrit P. Haase wrote: libpthread should be in the list of libraries where these tests are skipped, like it is for libstdc++ or libgcc and others, Nope. MAYBE it should be skipped, like -lc and -lm are skipped. But libstdc++ and libgcc are a different kettle of fish. libtool specifically checks for -lc and -lm on the command line, and has special purpose code to ignore them when running on cygwin. This was done as a convenience, back before the cygwin project provided the import stubs libc.a and libm.a, since many Makefiles blindly add -lc or -lm to their link commands. Now, of course, we have libm.a and libc.a import stubs, so this convenience is no longer necessary. But it doesn't hurt anything, so it's still there. (So you see, I don't really think it's a good idea to perpetuate the no-longer-necessary convenience by adding yet another special case library -lpthread.) Now, stuff like libstdc++ is handled differently. Libtool detects which flags and libs are added to the command line by the compiler driver (gcc, g++, etc) when linking a shared library. Needless to say, libpthread.a is not one of this type. if it is not included, try the snapshot Charles provided which includes probably some more cygwin related fixes than f-d = 2 versions before the current snapshot, and if this fails too, then please come back. (a) this problem originally arose because of an error in the user's configure.ac. However, once that was corrected, THIS part of libtool worked as expected (that is, correctly). I don't want to add yet another special case library to the -lc,-lm kludge; I'd rather *remove* the -lc,-lm special case since, with a properly configured system, it's not necessary. Will address other issue in separate message. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Peter Ekberg wrote:
I have a problem with "make install" of a built executable.
I'm confused.
Background: the only reason you ever need a wrapper script for an
executable in a libtoolized project, is when that executable depends on
an uninstalled shared library. You need the wrapper script to set PATH
(and LD_LIBRARY_PATH on other platforms) so that the runtime loader can
find the shared library.
BUT, if you do not depend on any (uninstalled) shared libraries, then
you don't need a wrapper script...so it shouldn't be created at all, and
the "real" executable should be in the build directory, not in .libs/
Its wrapper script contains:
---8<
relink_command=""
# This environment variable determines our operation mode.
if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
# install mode needs the following variable:
notinst_deplibs=''
else
---8<
This comes from this fragment:
if test \"\$libtool_install_magic\" = \"$magic\"; then
# install mode needs the following variable:
notinst_deplibs='$notinst_deplibs'
else
and make install fails with:
libtool: install: invalid libtool wrapper script `xsendbut'
This is because this test is true in ltmain.m4sh:
---8<
# Check the variables that should have been set.
test -z "$notinst_deplibs" && \
func_fatal_error "invalid libtool wrapper script
\`$wrapper'"
---8<
Adding a space between the '' in the wrapper script makes it
work, of course.
Right. This is part of the integrity checks built in to libtool --
since the ONLY thing you know about any exe wrapper script is it darn
well better define noninst_deplibs (otherwise, there should be no
wrapper). So, to check that it successfully sourced something that WAS
in fact a wrapper script, libtool tries to make sure that
notinst_deplibs got set. ('cause if it didn't, then there are probably
other significant problems, like an incorrect $relink_cmd, etc)
In your case, you have a wrapper script -- but an empty noninst_deplibs.
One of two things is true:
(1) your exe really truly does not depend on any uninstalled libraries.
--> so need to investigate WHY a wrapper script was created at all.
or
(2) your exe DOES have uninstalled library dependencies
--> so need to investigate WHY they went unrecorded in the wrapper.
Needless to say, I haven't observed that behavior here.
BTW, does your version of libtool contain this ChangeLog entry?
2004-10-09 Charles Wilson
* config/ltmain.m4sh (func_mode_link): don't relink
on cygwin/mingw; no need. But do ensure that wrappers
are created unless doing a purely static build.
'cause it touches exactly this bit of code.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote: > Peter Ekberg wrote: >> I have a problem with "make install" of a built executable. > In your case, you have a wrapper script -- but an empty > noninst_deplibs. One of two things is true: > > (1) your exe really truly does not depend on any uninstalled > libraries. --> so need to investigate WHY a wrapper script was > created at all. It does not. The reason seems to be that $wrappers_required does not get set to "no" since $build_libtool_libs is "yes" in this snippet from the libtool script: ---8<-- wrappers_required=yes case $host in *cygwin* | *mingw* ) if test "$build_libtool_libs" != yes; then wrappers_required=no fi ;; *) if test "$need_relink" = no || test "$build_libtool_libs" != yes; then wrappers_required=no fi ;; esac ---8<-- $build_libtool_libs gets set to "yes" in the very beginning of the libtool script and is not changed after that. If I add this project specific brown-paper-bag hack to the mix, "make install" works correctly: ---8<-- if test "$outputname" = "xsendbut.exe" ; then wrappers_required=no fi ---8<-- > Needless to say, I haven't observed that behavior here. > > BTW, does your version of libtool contain this ChangeLog entry? > > 2004-10-09 Charles Wilson > > * config/ltmain.m4sh (func_mode_link): don't relink > on cygwin/mingw; no need. But do ensure that wrappers > are created unless doing a purely static build. > > 'cause it touches exactly this bit of code. That patch is in there, the guy who merged libtool-1.9-cvs into the project claims that the only difference between our libtool version and 1.9f is the version number (and a totally unrelated local FreeBSD fix)... BTW, this is the command that generates the wrapper script when it shouldn't: /bin/sh ../libtool --mode=link --tag=CC gcc -g -O2 -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow -o xsendbut.exe xsendbut.o -L/usr/X11R6/lib -lX11 I should perhaps note that xsendbut resides in a directory where other executables are built that do indeed depend on uninstalled libtool libs, if that is at all relevant? On the off chance that you (or someone else) want to get first hand experience of the problem, try libgii from cvs available from: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ggi login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ggi co ggi-core/libgii cd ggi-core/libgii ./autogen.sh ./configure make make install xsendbut is in the demos subdir. Cheers, Peter -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote:
> New alpha versions of libtool available for test. This is
> very close to what libtool-2.0 will be. Please evaluate.
"make install-strip" on a shared library strips the import
lib, not the dll which was what I was hoping for.
Not a show-stopper I suppose...
/bin/sh ../libtool --mode=install /usr/bin/install -c -s 'libgg.la'
'/usr/lib/libgg.la'
/usr/bin/install -c .libs/libgg.dll.a /usr/lib/libgg.dll.a
strip --strip-unneeded /usr/lib/libgg.dll.a
base_file=`basename ${file}`
dlpath=`/bin/sh 2>&1 -c '. .libs/'${base_file}'i;echo $dlname'`
dldir=/usr/lib/`dirname $dlpath`
test -d $dldir || mkdir -p $dldir
/usr/bin/install -c .libs/cyggg-0.dll $dldir/cyggg-0.dll
/usr/bin/install -c .libs/libgg.lai /usr/lib/libgg.la
Cheers,
Peter
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Peter wrote: > Chuck wrote: >> New alpha versions of libtool available for test. This is >> very close to what libtool-2.0 will be. Please evaluate. > "make install-strip" on a shared library strips the import > lib, not the dll which was what I was hoping for. > Not a show-stopper I suppose... Yes, this is a showstopper! Import libraries may be broken after stripping. Gerrit -- =^..^= http://nyckelpiga.de/donate.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Gerrit P. Haase wrote: "make install-strip" on a shared library strips the import lib, not the dll which was what I was hoping for. Not a show-stopper I suppose... Yes, this is a showstopper! Import libraries may be broken after stripping. I'm going out of town for a few days, so in the words of a very wise man: patches gratefully considered -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote: > Gerrit P. Haase wrote: >>> "make install-strip" on a shared library strips the import >>> lib, not the dll which was what I was hoping for. >>> Not a show-stopper I suppose... >> >> Yes, this is a showstopper! Import libraries may be broken after >> stripping. > > I'm going out of town for a few days, so in the words of a very wise > man: > > patches gratefully considered Here you go... Patch against libtool-1.9f, works for me Cheers, Peter install-strip.patch Description: install-strip.patch -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Peter Ekberg wrote: BTW, this is the command that generates the wrapper script when it shouldn't: /bin/sh ../libtool --mode=link --tag=CC gcc -g -O2 -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow -o xsendbut.exe xsendbut.o -L/usr/X11R6/lib -lX11 I should perhaps note that xsendbut resides in a directory where other executables are built that do indeed depend on uninstalled libtool libs, if that is at all relevant? I don't know. I don't THINK so, but... On the off chance that you (or someone else) want to get first hand experience of the problem, try libgii from cvs available from: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ggi login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ggi co ggi-core/libgii cd ggi-core/libgii ./autogen.sh ./configure make make install xsendbut is in the demos subdir. Unfortunately my travel schedule won't allow me to look into this. It smells like there is a real problem in libtool somewhere, but darned if I know what it is. It seems like a design decision was made, that IF in a given project there are ANY libtool libs, then libtool will "know" about it by having build_libtool_libs set to "yes". And thus, every executable is *assumed* to be linked against those libs, and will therefore have a wrapper and be linked against those shared libs. Except in your case, you have ONE executable that is NOT linked against any shared libs...and the wrapper-check fails. Maybe the right answer here is to change the check so that instead of # Check the variables that should have been set. test -z "$notinst_deplibs" && \ func_fatal_error "invalid libtool wrapper script \`$wrapper'" it checks for some other magic instead (which would need to be added to the "make a wrapper" code) # Check the variables that should have been set. test -z "$generated_by_libtool_version" && \ func_fatal_error "invalid libtool wrapper script \`$wrapper'" where the "make a wrapper" code ensures that the following assignment appears in the wrapper ORIG> if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then ORIG> # install mode needs the following variables: ORIG> notinst_deplibs= NEW > generated_by_libtool_version=$macro_version ORIG> else Our check wouldn't care about the actual VALUE of $generated_by_libtool_version -- only that it was, in fact, set to SOMETHING. Can't flesh this out anymore right now, but you get the idea... -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote: > It seems like a design decision was made, that IF in a given project > there are ANY libtool libs, then libtool will "know" about it > by having > build_libtool_libs set to "yes". And thus, every executable is > *assumed* to be linked against those libs, and will therefore have a > wrapper and be linked against those shared libs. I have this feeling also. The right thing to do would perhaps be to not generate the wrapper in the first place, but that feels more complex than your proposal below... > Except in your case, you have ONE executable that is NOT > linked against > any shared libs...and the wrapper-check fails. > > Maybe the right answer here is to change the check so that instead of > ># Check the variables that should have been set. >test -z "$notinst_deplibs" && \ > func_fatal_error "invalid libtool wrapper script > \`$wrapper'" > > it checks for some other magic instead (which would need to > be added to > the "make a wrapper" code) > ># Check the variables that should have been set. >test -z "$generated_by_libtool_version" && \ > func_fatal_error "invalid libtool wrapper script > \`$wrapper'" > > where the "make a wrapper" code ensures that the following assignment > appears in the wrapper > > ORIG> if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then > ORIG> # install mode needs the following variables: > ORIG> notinst_deplibs= > NEW > generated_by_libtool_version=$macro_version > ORIG> else > > > Our check wouldn't care about the actual VALUE of > $generated_by_libtool_version -- only that it was, in fact, set to > SOMETHING. > > > Can't flesh this out anymore right now, but you get the idea... Yup, clear enough, here's a patch that does as you outlined. It even works :-). Thanks a bunch! Only one Cygwin related problem left on my list for libtool-1.9f, and that is linking a libtool shared lib against /usr/lib/w32api/libdxguid.a which is not recognized as an import lib (and probably isn't one either, I don't know). But it works to link a dll against it if I make it pass the import check by brute force... Any hints for that one? Cheers, Peter install-nodeps-wrapper.patch Description: install-nodeps-wrapper.patch -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
I wrote: > Chuck wrote: >> Gerrit P. Haase wrote: "make install-strip" on a shared library strips the import lib, not the dll which was what I was hoping for. Not a show-stopper I suppose... >>> >>> Yes, this is a showstopper! Import libraries may be broken after >>> stripping. >> >> I'm going out of town for a few days, so in the words of a very wise >> man: >> >> patches gratefully considered > > Here you go... > > Patch against libtool-1.9f, works for me Here's an update that properly quotes the argument to exit, I think. It also removes os2 from the mix, as os2 does not seem to work with import libs. At least not in the same way as cygwin/mingw/pw32... Cheers, Peter install-strip2.patch Description: install-strip2.patch -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1
Chuck wrote: > New alpha versions of libtool available for test. This is > very close to what libtool-2.0 will be. Please evaluate. Ok, I found another problem. You cannot add the flag -Werror-implicit-function-declaration to CFLAGS as that kills the build of the wrapper executable. While there, clean up some other warnings as well, so that -Werror also has a chance to work... Here's the make output without the patch: /bin/sh ../libtool --mode=link --tag=CC gcc -g -O2 -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow -Wnested-externs -Wredundant-decls -Werror-implicit-function-declaration -o demo.exe demo.o ../gii/libgii.la gcc -g -O2 -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow -Wnested-externs -Wredundant-decls -Werror-implicit-function-declaration -o .libs/demo.exe demo.o ../gii/.libs/libgii.dll.a /home/peda/ggi2-cygwin/libgii/gg/.libs/libgg.dll.a -lpthread libtool: link: creating demo.exe .libs/lt-demo.c:68:1: warning: "DEBUG" redefined :11:1: warning: this is the location of the previous definition .libs/lt-demo.c: In function `main': .libs/lt-demo.c:110: warning: control reaches end of non-void function .libs/lt-demo.c: In function `xstrdup': .libs/lt-demo.c:125: error: implicit declaration of function `strcpy' .libs/lt-demo.c:125: error: implicit declaration of function `strlen' .libs/lt-demo.c: In function `find_executable': .libs/lt-demo.c:241: error: implicit declaration of function `memcpy' .libs/lt-demo.c:179: warning: unused variable `st' .libs/lt-demo.c: In function `strendzap': .libs/lt-demo.c:288: error: implicit declaration of function `strcmp' Everything below the "libtool: link: creating demo.exe" line disappears with the patch. Cheers, Peter win32-wrapper-cleanup.patch Description: win32-wrapper-cleanup.patch -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
