Re: libtool fails with uninstalled frameworks and the -F flag

[Peter O'Gorman]

Hmm, -F should be passed through unmolested.

      # Flags to be passed through unchanged, with rationale:
      # -64, -mips[0-9]      enable 64-bit mode for the SGI compiler
      # -r[0-9][0-9]*        specify processor for the SGI compiler
      # -xarch=*, -xtarget=* enable 64-bit mode for the Sun compiler
      # +DA*, +DD*           enable 64-bit mode for the HP compiler
      # -q*                  compiler args for the IBM compiler
      # -m*, -t[45]*, -txscale* architecture-specific flags for GCC
      # -F/path              path to uninstalled frameworks, gcc on darwin
      # -p, -pg, --coverage, -fprofile-*  profiling flags for GCC
      # @file                GCC response files
      # -tp=*                Portland pgcc target processor selection
      # --sysroot=*          for sysroot support
      # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time 
optimization
      # -stdlib=*            select c++ std lib with clang
      -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
      -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| 
\
      -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-stdlib=*)

What version of GNU libtool are you using?

Peter


On Jan 31, 2014, at 3:06 PM, Michael C. Grant <address@hidden> wrote:

> Gary,
> 
> Sorry for the delay. I think I'm going to have to give up on this one. I'm 
> afraid my understanding of libtool internals as well as Darwin -framework 
> idiosyncracies are insufficient to the task.
> 
> Fortunately, the issue we were having with Octave compilation has been 
> resolved by other means (actually by forcing link-all-dependencies in libtool 
> whenever an uninstalled framework is encountered).
> 
> Feel free to close this for now. If I get ambitious and figure things out 
> more fully I will take another crack at it.
> 
> On Jan 13, 2014, at 8:50 PM, Gary V. Vaughan <address@hidden> wrote:
> 
>> Hi Michael,
>> 
>> [moved to libtool-patches list]
>> 
>> On Jan 14, 2014, at 11:45 AM, Michael C. Grant <address@hidden> wrote:
>> 
>>> I'm trying to compile GNU Octave and its new Qt GUI on a Mac OSX with 
>>> Homebrew. Homebrew installs the Qt frameworks in 
>>> /usr/local/Cellar/qt/4.8.5/lib, so after some fiddling with the configure 
>>> script I get this:
>>> 
>>> QT_LDFLAGS=-F/usr/local/Cellar/qt/4.8.5/lib
>>> QT_LIBS=-framework QtCore -framework QtGui -framework QtNetwork
>>> 
>>> However, the libtool script does not handle the -F argument through 
>>> properly, so it is stripped out of the linking process.
>>> 
>>> I created the following patch for the generated libtool script, which 
>>> causes libtool to treat -F exactly like it treats -L. This seems to do the 
>>> trick.
>>> 
>>> I did notice that scanning through past discussions that this has come up a 
>>> couple of times, but there is reluctance to provide full support for -F for 
>>> some reason. Perhaps the relative simplicity of this patch would convince 
>>> you to reconsider. I'm also discussing this with the Homebrew folks to see 
>>> if they would consider including in their formula, but they do prefer not 
>>> to use patches if they can help it.
>> 
>> Thanks for the patch.  Sorry I didn't reply to your earlier emails - I 
>> marked them for further attention, but didn't make the time to actually go 
>> back and respond.
>> 
>> My main worry is whether that changing libtool's treatment of -F is going to 
>> do something unexpected on another platform.  That said, apart from your 
>> conflating of -L and -F in the case branches with the patch you sent, I'm 
>> open to including it in the upcoming release if you don't mind reworking it 
>> a little?
>> 
>> Please keep the -L and -F branches separate, factoring the branch bodies 
>> into a shell function if necessary to prevent cut-n-pasting blocks of code 
>> between the two.  Bonus points if you could also make -F behave as before on 
>> all platforms but *-darwin*.
>> 
>> If you have github, I keep a mirror of libtool at 
>> http://github.com/gvvaughan/GNU-libtool, so that might be a more convenient 
>> way for you to submit a pull request than dropping patch attachments into 
>> the mailing list.
>> 
>> I have a couple of small fixes of my own that I need to polish and push, and 
>> then I'll do another round of platform testing to nail down what else is a 
>> show-stopper for a final pre-release.
>> 
>> Cheers,
>> -- 
>> Gary V. Vaughan (gary AT gnu DOT org)
> 
>