Re: Problems on Solaris 10 (sparc)
Hi Brandon, * Brandon Molnar wrote on Wed, May 03, 2006 at 07:49:00AM CEST: Thank you for the quick reply! I did not start the ./configure, make or make install under /opt/php. I extracted the php-5.1.2.tar.gz under my home directory in /export/home/brandon, then su'd to root to run the configure, make and make install from there. Should I remove the current /opt/php directory, extract the php-5.1.2.tar.gz file to /opt/php/somewhere and THEN run the ./configure, make and make install? Nah. I've looked at php-5.1.2. The package has a bug in that they need to use libtool --mode=install $(INSTALL) as installation command for all libtool libraries and all binaries that depend on uninstalled libtool libraries. (php does not use Automake, thus does not get this automatically.) AFAICS this bug is still in php-5.1.3 which cam out a couple of days ago. Could you please report this bug upstream and point to this discussion in case of any questions? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dependency_libs?
Am Tue, 2 May 2006 13:22:54 +0200 schrieb Andreas Volz: Perhaps my cross compiler enviroment isn't sane. If I don't use --without-x my hosts X installation is found: ... checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include ... Now I found a solution to really prevent linking against X: [cross compiler environment set] ./configure --x-includes=/tmp --x-libraries=/tmp --without-x The --without-x parameter isn't enough for libtool to assume no X is used. Without redirecting both path into a dead space the .la-file has everytime the -X* libraries in it. And it couldn't get the -lX* from a transitive .la because there's no .la in my cross compiler environment! I don't understand this. Is it a bug in libtool? regards Andreas ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dependency_libs?
Am Wed, 3 May 2006 10:31:31 +0200 schrieb Ralf Wildenhues: To be able to confirm or deny anything here, we would need much more information. configure log, build log, contents of all .la files Ok, at first I show the cross build of freeglut. Here is the packages configured and build: (log files and .la files included) http://brachttal.net/tmp/freeglut/freeglut-2.4.0-crosscompiler.tar.bz2 I've applied this patch to build it in my cross compiler environment: http://brachttal.net/tmp/freeglut/freeglut-2.4.0.patch and used this wrapper script for configure: http://brachttal.net/tmp/freeglut/conf_xmingw.sh So I configured it with: ./conf_xmingw.sh --without-x I tried also the parameter --enable-shared=no because I build the static library only, but this doesn't change anything. involved, possibly libtool --debug --mode=link output of the interesting library, ... (please bzip2 or gzip large attachments). Probably it's a limitation in the AC_PATH_X module, but for that, I'd need to see config.log as well, and know the Autoconf version used. All I can say from a general standpoint is that, if you do not install the .la files, you take away some functionality for users of your library. Yes, libtool has some issues with cross-compilation there, but in the normal, non-cross-compilation case, even on sane systems, the Debian link_all_deplibs=no libtool still has bugs that may cause third party users to link against the wrong installed library, or not find a user-installed (below $HOME, say) at all. So please don't recommend it unless you are also volunteering to attend the bug reports that ensue. And no, pkg-config does not provide the adequate replacement here. It seems the mingw environment doesn't provide much .la files. Are this files on Windows not as usefull as on Linux or UNIX? Yes, we'd like to fix all of that eventually.. I hope you could help me. If you need more information or I forgot to provide any files, than say it. regards Andreas ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: fail.at failing on HP-UX
Hi Albert,
Sorry for the delay.
* Albert Chin wrote on Sun, Apr 30, 2006 at 11:21:57PM CEST:
On Sun, Apr 30, 2006 at 05:09:23PM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sun, Apr 30, 2006 at 05:00:46PM CEST:
I'm getting the following test failure from HEAD on HP-UX 11.23/PA:
However, even though there is no main, `a' is still created. How do we
work around this?
Yes. I didn't finish this when I saw it, several weeks ago.
Bob suggested removing the binary in mode=link when an error occurred, I
am hesitant as the binary may still be useful for the clueful developer.
If cc doesn't remove it, libtool definitely should not.
OK. Let's not change it now.
Can we XFAIL it for now on *-hpux*? How do I do this?
No, that's ugly. Giving in on matching $host in the link-order test has
already created a maintenance hassle, and I want to revert this
eventually.
This should work. Let's just hope there is no legacy system where both
test -x doesn't work and the linker outputs broken binaries.
OK? (We can still factor it nicely in a macro should we need it
elsewhere.)
Cheers,
Ralf
* tests/fail.at: Use test -x if available, for testing of
executables; code modified from Autoconf's AS_EXECUTABLE_P.
Reported by Albert Chin [EMAIL PROTECTED].
Index: tests/fail.at
===
RCS file: /cvsroot/libtool/libtool/tests/fail.at,v
retrieving revision 1.3
diff -u -r1.3 fail.at
--- tests/fail.at 5 Feb 2006 09:56:44 - 1.3
+++ tests/fail.at 3 May 2006 16:11:23 -
@@ -28,6 +28,17 @@
[AT_CHECK([if $1; then (exit 1); else :; fi], [0], [ignore], [ignore])
])
+AT_DATA([script],
+[[#! /bin/sh
+exit 0
+]])
+chmod +x script
+if test -x script /dev/null 21; then
+ test_x=test -x
+else
+ test_x=:
+fi
+
# compile failure
echo 'choke me' a.c
FAIL_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c])
@@ -52,9 +63,9 @@
echo 'int not_main(void) { return 0; }' a.c
$CC $CPPFLAGS $CFLAGS -c a.c
FAIL_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a a.$OBJEXT])
-AT_CHECK([test -f a || test -f a$EXEEXT], [1])
+AT_CHECK([{ test -f a $test_x a; } || { test -f a$EXEEXT $test_x
a$EXEEXT; }], [1])
FAIL_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a a.$OBJEXT -static])
-AT_CHECK([test -f a || test -f a$EXEEXT], [1])
+AT_CHECK([{ test -f a $test_x a; } || { test -f a$EXEEXT $test_x
a$EXEEXT; }], [1])
# shared library creation failure
case $build_libtool_libs in yes)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: fail.at failing on HP-UX
On Wed, May 03, 2006 at 06:16:46PM +0200, Ralf Wildenhues wrote: This should work. Let's just hope there is no legacy system where both test -x doesn't work and the linker outputs broken binaries. OK? (We can still factor it nicely in a macro should we need it elsewhere.) It works fine. Thanks. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dependency_libs?
* Andreas Volz wrote on Wed, May 03, 2006 at 03:23:40PM CEST: Am Wed, 3 May 2006 10:31:31 +0200 schrieb Ralf Wildenhues: To be able to confirm or deny anything here, we would need much more information. configure log, build log, contents of all .la files Ok, at first I show the cross build of freeglut. Here is the packages configured and build: (log files and .la files included) Thanks. The first point where the X11 libraries come into play even when --without-x is given is in src/Makefile.am, where they are added unconditionally to [EMAIL PROTECTED]@_la_LIBADD. I'm not an expert with freeglut, and which libraries it needs in which situation; you might want to ask the maintainer of the package to conditionalize this appropriately. (Automake conditionals are one convenient way to achieve this.) http://brachttal.net/tmp/freeglut/conf_xmingw.sh which is this: PATH=/opt/xmingw/bin/:/opt/xmingw/i386-mingw32msvc/bin/:$PATH CC=i386-mingw32msvc-gcc CFLAGS= LDFLAGS=-L/opt/xmingw/i386-mingw32msvc/lib CPPFLAGS=-I/opt/xmingw/i386-mingw32msvc/include CPP=i386-mingw32msvc-cpp CXX=i386-mingw32msvc-g++ CXXFLAGS= CXXCPP=i386-mingw32msvc-cpp export PATH CC CFLAGS LDFLAGS CPPFLAGS CPP CXX CXXFLAGS CXXCPP ./configure --host=i386-mingw32msvc \ --target=i386-mingw32msvc \ $@ With package using non-ancient autotools, it should be possible to reduce this to PATH=/opt/xmingw/bin:/opt/xmingw/i386-mingw32msvc/bin:$PATH export PATH ./configure --host=i386-mingw32msvc \ LDFLAGS=-L/opt/xmingw/i386-mingw32msvc/lib \ CPPFLAGS=-I/opt/xmingw/i386-mingw32msvc/include \ $@ (except now configure will set CFLAGS and CXXFLAGS; so set them if you don't want that). I tried also the parameter --enable-shared=no because I build the static library only, but this doesn't change anything. Yes, that's because of the reason stated above. It seems the mingw environment doesn't provide much .la files. Are this files on Windows not as usefull as on Linux or UNIX? No. They are intended to be useful on all systems that Libtool supports. Some distributors choose not to ship them; often though, the respective libraries just aren't built with libtool. If you need more information or I forgot to provide any files, than say it. This wasn't the library you intended to build, but a dependent one. There may be more issues ahead in the other one (and further dependencies). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Problems on Solaris 10 (sparc)
Hi Ralf, After looking around on the PHP bug site, I found out that my problem isn't a bug with PHP or libtool at all! It was actually a problem with the pre-installed version of Net-SNMP 5.0.9 with Solaris 10. I grabbed a pre-compiled version of Net-SNMP 5.1.4 from sunfreeware.com and was able to then re-compile and run CLI PHP with no errors! Thank you very much for all your help! Brandon -Original Message- From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 2:35 AM To: Brandon Molnar Cc: libtool@gnu.org Subject: Re: Problems on Solaris 10 (sparc) Hi Brandon, * Brandon Molnar wrote on Wed, May 03, 2006 at 07:49:00AM CEST: Thank you for the quick reply! I did not start the ./configure, make or make install under /opt/php. I extracted the php-5.1.2.tar.gz under my home directory in /export/home/brandon, then su'd to root to run the configure, make and make install from there. Should I remove the current /opt/php directory, extract the php-5.1.2.tar.gz file to /opt/php/somewhere and THEN run the ./configure, make and make install? Nah. I've looked at php-5.1.2. The package has a bug in that they need to use libtool --mode=install $(INSTALL) as installation command for all libtool libraries and all binaries that depend on uninstalled libtool libraries. (php does not use Automake, thus does not get this automatically.) AFAICS this bug is still in php-5.1.3 which cam out a couple of days ago. Could you please report this bug upstream and point to this discussion in case of any questions? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
