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 <m...@cvxr.com> 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 <g...@gnu.org> wrote: > >> Hi Michael, >> >> [moved to libtool-patches list] >> >> On Jan 14, 2014, at 11:45 AM, Michael C. Grant <m...@cvxr.com> 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) > >