date:20110119

[PATCH] Darwin - verbose linker messages influence configure results.

2011-01-19 Thread Peter O'Gorman


Hi,

Jeremy reported this ages and ages ago, and I promptly forgot about it 
(sorry). David reported it again yesterday.


Darwin's linker can be quite verbose, if it sees an -L path that does 
not exist it prints a warning on stderr. Jeremy needs to configure with 
-L paths that don't exist at configure time (because they will exist 
later), and would like to be able to debug the result, so detecting 
-force_load properly would be helpful.


Davids problem was about failing to detect -single_module, same issue.

I only have Mac OS X 10.6 systems, and I am much too lazy to check what 
older linkers did when they saw flags they didn't recognize, so this 
patch greps stderr for flag and assumes the linker didn't recognize it 
if is there. I think all Darwin ld's exit with an error for flags they 
don't recognize, so even that is probably not necessary, but I am not 
100% sure of that.


Jeremy, I set RC_TRACE_ARCHIVES, RC_TRACE_DYLIBS, 
RC_TRACE_DYLIB_SEARCHING to check that none of those env vars caused ld 
to print its arguments on stderr, and they didn't. Are there any env 
vars set when building the OS that would cause that to happen? If so I 
will change this patch to just assume that ld exits with an error code 
for unrecognized arguments.


Patch Ok?

Peter


From 4f0eb4701ae67e7e52dcc4cb8eb7eb65f11645d3 Mon Sep 17 00:00:00 2001
From: Peter O'Gorman pe...@pogma.com
Date: Wed, 19 Jan 2011 10:09:46 -0600
Subject: [PATCH] Don't let verbose linker messages influence test results.

* libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Ignore
stderr during tests for -flag unless it contains flag.
* tests/darwin.at: Add test.
Reported by Jeremy Huddleston and also by David Fang.
---
 ChangeLog |8 
 libltdl/m4/libtool.m4 |   14 --
 tests/darwin.at   |   26 +-
 3 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1ad3741..640f4a1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2011-01-19  Peter O'Gorman  pe...@pogma.com
+
+	Don't let verbose linker messages influence test results.
+	* libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Ignore
+	stderr during tests for -flag unless it contains flag.
+	* tests/darwin.at: Add test.
+	Reported by Jeremy Huddleston and also by David Fang.
+
 2011-01-09  John David Anglin  dave.ang...@nrc-cnrc.gc.ca  (tiny change)
 
 	Fix relink mode to use absolute path if hardcode_minus_L.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index fd79dcf..706a2df 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -986,7 +986,13 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
 	$LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
 	  -dynamiclib -Wl,-single_module conftest.c 2conftest.err
 _lt_result=$?
-	if test -f libconftest.dylib  test ! -s conftest.err  test $_lt_result = 0; then
+	# If there is a non-empty error log, and single_module
+	# appears in it, assume the flag caused a linker warning
+if test -s conftest.err  $GREP single_module conftest.err; then
+	  cat conftest.err AS_MESSAGE_LOG_FD
+	# Otherwise, if the output was created with a 0 exit code from
+	# the compiler, it worked.
+	elif test -f libconftest.dylib  test $_lt_result = 0; then
 	  lt_cv_apple_cc_single_mod=yes
 	else
 	  cat conftest.err AS_MESSAGE_LOG_FD
@@ -994,6 +1000,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
 	rm -rf libconftest.dylib*
 	rm -f conftest.*
   fi])
+
 AC_CACHE_CHECK([for -exported_symbols_list linker flag],
   [lt_cv_ld_exported_symbols_list],
   [lt_cv_ld_exported_symbols_list=no
@@ -1005,6 +1012,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
 	[lt_cv_ld_exported_symbols_list=no])
 	LDFLAGS=$save_LDFLAGS
 ])
+
 AC_CACHE_CHECK([for -force_load linker flag],[lt_cv_ld_force_load],
   [lt_cv_ld_force_load=no
   cat  conftest.c  _LT_EOF
@@ -1022,7 +1030,9 @@ _LT_EOF
   echo $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c -Wl,-force_load,./libconftest.a AS_MESSAGE_LOG_FD
   $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c -Wl,-force_load,./libconftest.a 2conftest.err
   _lt_result=$?
-  if test -f conftest  test ! -s conftest.err  test $_lt_result = 0  $GREP forced_load conftest 21 /dev/null; then
+  if test -s conftest.err  $GREP force_load conftest.err; then
+	cat conftest.err AS_MESSAGE_LOG_FD
+  elif test -f conftest  test $_lt_result = 0  $GREP forced_load conftest 21 /dev/null; then
 	lt_cv_ld_force_load=yes
   else
 	cat conftest.err AS_MESSAGE_LOG_FD
diff --git a/tests/darwin.at b/tests/darwin.at
index bb71207..4e5034e 100644
--- a/tests/darwin.at
+++ b/tests/darwin.at
@@ -1,6 +1,6 @@
 # darwin.at - tests specific to Mac OS X
 #
-#   Copyright (C) 2008, 2009 Free Software Foundation, Inc.
+#   Copyright (C) 2008, 2009, 2011 Free Software Foundation, Inc.
 #   Written by Peter O'Gorman, 2008
 #
 #   This file is part of GNU Libtool.
@@ -204,3 +204,27 @@ AT_CHECK([echo quit

Re: [PATCH] Darwin - verbose linker messages influence configure results.

2011-01-19 Thread Ralf Wildenhues

Hi Peter,

* Peter O'Gorman wrote on Wed, Jan 19, 2011 at 05:26:26PM CET:
 Patch Ok?

If it turns the testsuite addition from failing to passing, yes,
with a couple of nits below fixed.

Thanks,
Ralf

 Subject: [PATCH] Don't let verbose linker messages influence test results.
 
 * libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Ignore
 stderr during tests for -flag unless it contains flag.
 * tests/darwin.at: Add test.
 Reported by Jeremy Huddleston and also by David Fang.

 --- a/libltdl/m4/libtool.m4
 +++ b/libltdl/m4/libtool.m4
 @@ -986,7 +986,13 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
   $LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
 -dynamiclib -Wl,-single_module conftest.c 2conftest.err
  _lt_result=$?
 - if test -f libconftest.dylib  test ! -s conftest.err  test 
 $_lt_result = 0; then
 + # If there is a non-empty error log, and single_module
 + # appears in it, assume the flag caused a linker warning
 +if test -s conftest.err  $GREP single_module conftest.err; then
 +   cat conftest.err AS_MESSAGE_LOG_FD
 + # Otherwise, if the output was created with a 0 exit code from
 + # the compiler, it worked.
 + elif test -f libconftest.dylib  test $_lt_result = 0; then

-eq instead of =

 lt_cv_apple_cc_single_mod=yes
   else
 cat conftest.err AS_MESSAGE_LOG_FD
 @@ -994,6 +1000,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
   rm -rf libconftest.dylib*
   rm -f conftest.*
fi])
 +
  AC_CACHE_CHECK([for -exported_symbols_list linker flag],
[lt_cv_ld_exported_symbols_list],
[lt_cv_ld_exported_symbols_list=no
 @@ -1005,6 +1012,7 @@ m4_defun_once([_LT_REQUIRED_DARWIN_CHECKS],[
   [lt_cv_ld_exported_symbols_list=no])
   LDFLAGS=$save_LDFLAGS
  ])
 +
  AC_CACHE_CHECK([for -force_load linker flag],[lt_cv_ld_force_load],
[lt_cv_ld_force_load=no
cat  conftest.c  _LT_EOF
 @@ -1022,7 +1030,9 @@ _LT_EOF
echo $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c 
 -Wl,-force_load,./libconftest.a AS_MESSAGE_LOG_FD
$LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c 
 -Wl,-force_load,./libconftest.a 2conftest.err
_lt_result=$?
 -  if test -f conftest  test ! -s conftest.err  test $_lt_result = 0 
  $GREP forced_load conftest 21 /dev/null; then
 +  if test -s conftest.err  $GREP force_load conftest.err; then
 + cat conftest.err AS_MESSAGE_LOG_FD
 +  elif test -f conftest  test $_lt_result = 0  $GREP forced_load 
 conftest 21 /dev/null; then

Likewise.

Also, /dev/null 21  (order matters!)

Are you really grepping the binary intentionally here, rather than the
.err file?

   lt_cv_ld_force_load=yes
else
   cat conftest.err AS_MESSAGE_LOG_FD

Re: [PATCH] Darwin - verbose linker messages influence configure results.

2011-01-19 Thread Peter O'Gorman


On 01/19/2011 12:38 PM, Ralf Wildenhues wrote:

Hi Ralf,

Thanks for the quick review! Yes, the testsuite addition fails before 
the patch, and passes after.




Also,/dev/null 21  (order matters!)

Are you really grepping the binary intentionally here, rather than the
.err file?


Yes, and that will cause problems when cross-compiling to Mac OS X on 
systems without GNU grep (or an equivalent grep that greps binary 
files), sigh. However, I doubt that is a major issue right now.


I will push the patch with nits addressed later on today.

Peter

[PATCH] libtool.m4: remove (incorrect) handling of FreeBSD 1.x

2011-01-19 Thread Gerald Pfeifer

FreeBSD has been dead for way over a decade (FreeBSD 2.0 was released
in 1994) and without support for dynamic linking and shared libraries
I doubt there's a lot of software that would build at all.

In anycase, libtool's handling code to handle it is buggy and will soon 
also match FreeBSD 10.0 and later which do support dynamic linking.


I think it's best to simplify libtool.m4 per the patch below.

I do not have libtool write access, so appreciate help.  Let me know
how to handle this for GCC, where this should go to HEAD, 4.5 and 4.4
at least.


Thanks,
Gerald


2011-01-19  Gerald Pfeifer  ger...@pfeifer.com

* libtool.m4: Remove handling of freebsd1* which soon would
incorrectly match FreeBSD 10.0.

Index: libtool.m4
===
--- libtool.m4  (revision 168842)
+++ libtool.m4  (working copy)
@@ -2266,10 +2266,6 @@
   shlibpath_var=LD_LIBRARY_PATH
   ;;
 
-freebsd1*)
-  dynamic_linker=no
-  ;;
-
 freebsd* | dragonfly*)
   # DragonFly does not have aout.  When/if they implement a new
   # versioning mechanism, adjust this.
@@ -4796,10 +4792,6 @@
   _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
   ;;
 
-freebsd1*)
-  _LT_TAGVAR(ld_shlibs, $1)=no
-  ;;
-
 # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
 # support.  Future versions do this automatically, but an explicit c++rt0.o
 # does not break anything, and helps significantly (at the cost of a little

Re: Stop relink searching host directory when installation prefix provided

2011-01-19 Thread Martin Panter

On 16 January 2011 17:13, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
 I haven't looked into this in detail yet, but thanks for the good
 writeup and the many references.  We need testsuite exposure for
 this.

Hello again

I've made a test case for my issue (attached patch file). It fails
with current Libtool and if you remove the XFAIL line it passes with
my solution applied. I'm just guessing the syntax etc based on the
other tests, so I wouldn't say it's perfect, but hopefully you can see
what I'm trying to do from the comments.

When I ran all the tests with make -k check there are no issues with
the rest of the tests, with or without my patch.

I understand this relinking (at least on Linux) is only needed to
remove hard-coded build directory paths to library dependencies that
Libtool stores during the initial link, which are only put there as a
convenience before things are properly installed. So perhaps a less
controversial solution or workaround to my problem would be an easy
way to disable these convenient build paths and thus the relinking
completely? But I still don't see a problem with my original solution.

-Martin
Index: libtool-2.4+host-relink/tests/destdir.at
===
--- libtool-2.4+host-relink.orig/tests/destdir.at
+++ libtool-2.4+host-relink/tests/destdir.at
@@ -139,4 +139,54 @@ fi
 
 AT_CLEANUP
 
+
+AT_SETUP([Not relinking against host library])
+AT_KEYWORDS([libtool])
+
+_LT_DIRSETUP
+trickydir=$(pwd)/trickydir
+rm -rf $trickydir
+$mkdir_p $trickydir
+cd src
+
+# Create real libtricky and install directly into $trickydir
+echo int tricky() { return 0; }  tricky.c
+$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c tricky.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libtricky.la tricky.lo -rpath 
$trickydir
+$LIBTOOL --mode=install cp libtricky.la $trickydir/libtricky.la
+$LIBTOOL --mode=clean rm -f libtricky.la
+
+# Create libdep, to be eventually installed into target's /$prefix, that
+# depends on libtricky
+echo extern int tricky(); int dep() { return tricky(); }  dep.c
+$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c -o dep.lo dep.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -L$trickydir -ltricky -o libdep.la 
-rpath $prefix dep.lo
+
+# Create libtest, to also be eventually installed into target's /$prefix,
+# that depends on libdep
+echo extern int tricky(), dep(); int test() { return dep() + tricky(); }  
test.c
+$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c -o test.lo test.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS libdep.la -o libtest.la -rpath 
$prefix test.lo
+
+# Install libdep into $DESTDIR/$prefix
+$LIBTOOL --mode=install cp libdep.la $DESTDIR$prefix
+
+# Create false libtricky and install directly into host's /$prefix
+# Not sure of a perfectly portable way of doing this; currently using an
+# empty lib.so file. With GCC this fails for me with the message
+#   libtricky.so: file not recognized: File truncated
+:  $prefix/libtricky.so
+
+# Install libtest to trigger a relink. Relink command should be like
+#   $CC -o libtest.so test.o -L$DESTDIR$prefix -ldep -L$trickydir -ltricky
+# not like
+#   $CC -o libtest.so test.o -L$DESTDIR$prefix -L$prefix -ldep 
-L$trickydir -ltricky
+# Verify that the relink succeeds and it didn't search $prefix or find the
+# false libtricky there
+AT_XFAIL_IF([true])
+AT_CHECK([$LIBTOOL --mode=install cp libtest.la $DESTDIR$prefix],
+  [0], [ignore], [ignore])
+
+AT_CLEANUP
+
 m4_popdef([_LT_DIRSETUP])

[PATCH] Darwin - verbose linker messages influence configure results.

Re: [PATCH] Darwin - verbose linker messages influence configure results.

Re: [PATCH] Darwin - verbose linker messages influence configure results.

[PATCH] libtool.m4: remove (incorrect) handling of FreeBSD 1.x

Re: Stop relink searching host directory when installation prefix provided

5 matches

Site Navigation

Mail list logo

Footer information