libtool-patches
[Top][All Lists]
Advanced

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

Re: darwin patches for HEAD


From: Ralf Wildenhues
Subject: Re: darwin patches for HEAD
Date: Wed, 9 Jan 2008 20:47:55 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello Peter,

* Peter O'Gorman wrote on Wed, Jan 09, 2008 at 07:10:24AM CET:
> Fails lt_dlopenadvise library loading on darwin6 (but that is not a
> regression, fails without this patch too).
> 
> Ran the tests on i386-darwin9 and (very slowly on) ppc-darwin6.
> 
> Ok to apply?

Not like this, sorry.  Some comments below.

> 2008-01-08  Peter O'Gorman  <address@hidden>
> 
>    * libltdl/m4/libtool.m4 [darwin]: Reorganize darwin support, use
>    dsymutil if it is available so that debugging is possible, check
>    for nmedit and dsymutil with AC_CHECK_TOOL, use the linker flag
>    -exported_symbols_list in preference to nmedit if it is available.

>    Drop support for xlc, it is probably broken.

Do you know it is broken, or just guess?  Or does this patch just
intentionally break it.  This would be a regression over branch-1-5.  
(I'm not saying that I have a problem with the removal, your call.)

>    * tests/template.at [darwin]: Skip this test, I can not find a way
>    to make it work on darwin9 with Xcode-3.0.
>    * NEWS: Note the dropping of xlc support.
> 

> --- NEWS      8 Jan 2008 05:11:14 -0000       1.212
> +++ NEWS      9 Jan 2008 03:08:38 -0000
> @@ -77,6 +77,7 @@
>  
>  * Changes in supported systems or compilers:
>  
> +  - Removed bitrotted support for xlc on Mac OS X.
>    - Detection of compiler wrappers distcc/ccache and $host_alias prefix.
>    - Basic support for PIE (position-independent executables).
>    - Support for DragonFly BSD, improved support for FreeBSD.
> Index: libltdl/m4/libtool.m4
> ===================================================================
> RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
> retrieving revision 1.127
> diff -u -r1.127 libtool.m4
> --- libltdl/m4/libtool.m4     8 Jan 2008 19:43:29 -0000       1.127
> +++ libltdl/m4/libtool.m4     9 Jan 2008 03:08:42 -0000
> @@ -888,6 +888,112 @@
>  $RM -r conftest*
>  ])# _LT_LINKER_BOILERPLATE
>  
> +# _LT_REQUIRED_DARWIN_TOOLS
> +# -------------------------
> +m4_defun([_LT_REQUIRED_DARWIN_TOOLS],[
> +  AC_CHECK_TOOL([DSYMUTIL], [dsymutil], [:])
> +  AC_CHECK_TOOL([NMEDIT], [nmedit], [:])
> +  _LT_DECL([], [DSYMUTIL], [1],
> +    [])
> +  _LT_DECL([], [NMEDIT], [1],
> +    [])

Can you provide a short description of these tools in the _LT_DECL?
By looking at the names alone, I wouldn't even think they are connected
with darwin at all, nor really know what they do.

> +])
> +
> +
> +# _LT_DARWIN_LINKER_FEATURES
> +# --------------------------

Hmm.  This factorization addresses a general problem (high amount of
repetition in the linker feature macros) but only for a specific case
(namely darwin).  I'm not too fond of going this way, because in the end
it will make the code even less readable, esp. if the refactoring will
cause even more repetition in the expanded configure script.  Of course
I don't want to start refactoring those huge macros myself either (and
all the less right now).  Sigh.

> +# Checks for linker and compiler features on darwin
> +m4_defun([_LT_DARWIN_LINKER_FEATURES],
> +[
> +m4_require([_LT_REQUIRED_DARWIN_TOOLS])

> +m4_case([$1],
> +  [C], [withGCC=$GCC],
> +  [CXX], [withGCC=$GXX],
> +  [F77], [withGCC=$G77],
> +  [FC], [withGCC=$ac_cv_fc_compiler_gnu],
> +  [GCJ], [withGCC=$GCC],
> +  [], [withGCC=$GCC],
> +  [withGCC=$GCC])

Why is this hunk necessary even?  The macros that call
_LT_DARWIN_LINKER_FEATURES should have withGCC set correctly,
and if not, then that is a bug in those macros.
Rationale: it's very confusing if you read the expanded configure
script and have generic variables be initialized in the middle of
some case statement.

> +  _LT_TAGVAR(archive_cmds_need_lc, $1)=no
> +  _LT_TAGVAR(hardcode_direct, $1)=no
> +  _LT_TAGVAR(hardcode_automatic, $1)=yes
> +  _LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
> +  _LT_TAGVAR(whole_archive_flag_spec, $1)=''
> +  _LT_TAGVAR(link_all_deplibs, $1)=yes
[...]

In the rest, I haven't spotted any obvious issues.  However, I tried to
run it on a powerpc-apple-darwin8.11.0 system which I have access to.
The
  export MACOSX_DEPLOYMENT_TARGET=10.3
  ./configure MACOSX_DEPLOYMENT_TARGET=10.3

run failed at `make' time:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2 -no-undefined 
-version-info 7:0:0 -dlpreopen libltdl/dlopen.la   -o libltdl/libltdl.la -rpath 
/u/rwildeha/local/powerpc-apple-darwin8.2.0/lib 
libltdl/loaders/libltdl_libltdl_la-preopen.lo 
libltdl/libltdl_libltdl_la-lt__alloc.lo 
libltdl/libltdl_libltdl_la-lt_dlloader.lo 
libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo 
libltdl/libltdl_libltdl_la-slist.lo libltdl/argz.lo
libtool: link: rm -f libltdl/.libs/libltdl.nm libltdl/.libs/libltdl.nmS 
libltdl/.libs/libltdl.nmT
libtool: link: creating libltdl/.libs/libltdlS.c
libtool: link: extracting global C symbols from `libltdl/.libs/dlopen.a'
libtool: link: (cd libltdl/.libs && gcc -g -O2 -c -fno-builtin  -fno-common 
-DPIC "libltdlS.c")
libtool: link: rm -f "libltdl/.libs/libltdlS.c" "libltdl/.libs/libltdl.nm" 
"libltdl/.libs/libltdl.nmS" "libltdl/.libs/libltdl.nmT"
libtool: link: rm -fr  libltdl/.libs/libltdl.7.dylib libltdl/.libs/libltdl.lax
libtool: link: Extracting 
/u/rwildeha/lt/build-darwin-noflat/libltdl/.libs/dlopen.a
libtool: link: (cd libltdl/.libs/libltdl.lax/dlopen.a && ar x 
"/u/rwildeha/lt/build-darwin-noflat/libltdl/.libs/dlopen.a")
libtool: link: gcc -dynamiclib  -o libltdl/.libs/libltdl.7.dylib  
libltdl/loaders/.libs/libltdl_libltdl_la-preopen.o 
libltdl/.libs/libltdl_libltdl_la-lt__alloc.o 
libltdl/.libs/libltdl_libltdl_la-lt_dlloader.o 
libltdl/.libs/libltdl_libltdl_la-lt_error.o 
libltdl/.libs/libltdl_libltdl_la-ltdl.o 
libltdl/.libs/libltdl_libltdl_la-slist.o libltdl/.libs/argz.o 
libltdl/.libs/libltdlS.o  libltdl/.libs/libltdl.lax/dlopen.a/dlopen.o      
-install_name  /u/rwildeha/local/powerpc-apple-darwin8.2.0/lib/libltdl.7.dylib 
-compatibility_version 8 -current_version 8.0 -Wl,-single_module
libtool: link: dsymutil libltdl/.libs/libltdl.7.dylib
ERROR: No debug map or DWARF data was found to link.make[2]: *** 
[libltdl/libltdl.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


The run without MACOSX_DEPLOYMENT_TARGET went further but not much
better, lots of failures and SKIPs in the old testsuite (before your
patch, there were no failures at all).  Example failure:
demo-make.test after demo-conf.test:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2 -no-undefined 
-version-info 3:12:1  -o libhello.la -rpath 
/u/rwildeha/lt/build-darwin/_inst/lib hello.lo foo.lo
libtool: link: gcc -dynamiclib  -o .libs/libhello.2.dylib  .libs/hello.o 
.libs/foo.o      -install_name  
/u/rwildeha/lt/build-darwin/_inst/lib/libhello.2.dylib
-compatibility_version 4 -current_version 4.12 -Wl,-single_module
libtool: link: dsymutil .libs/libhello.2.dylib
ERROR: No debug map or DWARF data was found to link.make[4]: *** [libhello.la] 
Error 1


I haven't tried any LT_MULTI_MODULE runs yet (should I try combining
that with MACOSX_DEPLOYMENT_TARGET also?).

Cheers,
Ralf




reply via email to

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