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: Thu, 10 Jan 2008 20:18:01 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hi Peter,

* Peter O'Gorman wrote on Thu, Jan 10, 2008 at 08:43:38AM CET:
> Ralf Wildenhues wrote:
> 
> > 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.
> 
> Sorry, I looked and thought "I can make my life easier" and took the
> opportunity.

Yeah, but at some expense.  Oh well.

> I have addressed the issue of the configure script
> repetition in this newer patch. m4_defun_once to check for things that
> we only need to check for one time. I hope that does what I think it does...

Not sure.  It would have probably been cleaner to just invoke
_LT_REQUIRED_DARWIN_TOOLS once outside the per-tag macros.
But if it expands right, then ok.

> >> +# 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.
> 
> Turns out that it is necessary, I can commit to removing it by fixing
> the offending macros after this commit if you like ( and then removing
> this ugliness).

Yes, please.  Thank you.

> > 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
> 
> For this I just cheated and do dsymutil libfoo.dylib || :.

You just signed up for addressing all future bug reports that report
this error and wonder whether they've done something wrong.  ;-)

> 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.
>       * 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.

This tests well for me.  No failures, I tried the four combinations
single/multi-module and flat/noflat.  No Fortran compilers though.

I noted that test 5 (upgrading verbatim style aclocal.m4) relies on a
new-enough aclocal version not specified well enough (1.6.x doesn't
suffice).

Cheers,
Ralf




reply via email to

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