bugGNU Octave - Bugs: bug #41236, Configure fails to find Qt...

 
 

bug #41236: Configure fails to find Qt frameworks if not installed in system locations (patch provided)

Submitted by:  Michael C. Grant <mcgrant>
Submitted on:  Wed 15 Jan 2014 06:05:51 AM UTC  
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Michael C. Grant Open/Closed:  Closed
Release:  dev Operating System:  Mac OS

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 13 Feb 2014 12:00:51 AM UTC, comment #18: 

Actually, it looks like I had better submit a new bug report.

Michael C. Grant <mcgrant>
Wed 12 Feb 2014 11:54:25 PM UTC, comment #17: 

It turns out that this fix causes mkoctfile to link to everything under the sun, which makes redistributing MEX/OCT files difficult. On octave-maintainers, JWE agreed this was something that needs to be fixed. I've fixed it by creating a new AMCOND_LINK_GUI_DEPS variable that targets just the GUI libraries. Changeset attached (macgui.diff)

(file #30529)

Michael C. Grant <mcgrant>
Fri 24 Jan 2014 10:41:43 PM UTC, comment #16: 

Added second part of fix here (http://hg.savannah.gnu.org/hgweb/octave/rev/97984c1c41f0).  Closing report.

Rik <rik5>
Project Administrator
Fri 24 Jan 2014 09:07:32 PM UTC, comment #15: 

That's great to hear, thanks. Sorry again for the regression.

Here's what this fix does: first, it looks for a standard library set (-L/-l) using the old approach. If it finds none, and we're running Mac OS, then it looks for a framework set (-F/-framework). If that succeeds, and at least one '-F' flag is present, then it enables "link-all-deps" to ensure that the final linking steps get that -F flag.

In comment 3, I was using a "+=" approach to combine any library and framework flags together. That's probably fine; however, it seems clear that with Qt you're going to have either a framework set or a library set, and not both. Indeed, if you had both, there is likely to be a conflict. So going with an exclusive or seems best.

Michael C. Grant <mcgrant>
Fri 24 Jan 2014 09:02:15 PM UTC, comment #14: 

Michael,

Your fix (file #30357) works for me.

Ben Abbott <bpabbott>
Project Member
Fri 24 Jan 2014 04:59:52 AM UTC, comment #13: 

Ben, please try applying patch-config.diff on top of Rik's changeset, and see if that rectifies the problem. This change will cause configure to search for a framework Qt only if it fails to find libraries.

(file #30357)

Michael C. Grant <mcgrant>
Fri 24 Jan 2014 04:39:07 AM UTC, comment #12: 

Actually, I know the problem: I thought I had written this patch to include both library and framework locations, but the way it has ended up here it will overwrite the library locations on Darwin. In other words, there are '=' assignments where there should be "+=". I will fix this. Stay tuned.

Michael C. Grant <mcgrant>
Fri 24 Jan 2014 04:17:06 AM UTC, comment #11: 

Actually, if you'll attach your configure log and a dump of your compile output, I can study it. This one frustrated me for some time, and in fact I got messages that looked very similar to this at first.

One thing you can try is adding --enable-link-all-dependencies to your configure flags.

Michael C. Grant <mcgrant>
Fri 24 Jan 2014 03:56:32 AM UTC, comment #10: 

I've been using Qt libs provided by macports. With the changeset Rik just pushed, but build now fails with several errors.  The last of which are

  "non-virtual thunk to QWidget::devType() const", referenced from:
      vtable for QTerminal in libqterminal.a(qterminal_libqterminal_la-moc-QTerminal.o)
      vtable for QUnixTerminalImpl in libqterminal.a(qterminal_libqterminal_la-moc-QUnixTerminalImpl.o)
      vtable for TerminalView in libqterminal.a(qterminal_libqterminal_la-moc-TerminalView.o)
      vtable for FileTreeViewer in libgui-src.a(src_libgui_src_la-files-dock-widget.o)
      vtable for file_editor_interface in libgui-src.a(src_libgui_src_la-moc-file-editor-interface.o)
      vtable for file_editor_tab in libgui-src.a(src_libgui_src_la-moc-file-editor-tab.o)
      vtable for file_editor in libgui-src.a(src_libgui_src_la-moc-file-editor.o)
      ...
  "operator==(QLatin1String const&, QStringRef const&)", referenced from:
      file_editor::request_new_function(bool)   in libgui-src.a(src_libgui_src_la-file-editor.o)
  "operator==(QString const&, QStringRef const&)", referenced from:
      file_editor::request_new_function(bool)   in libgui-src.a(src_libgui_src_la-file-editor.o)
ld: symbol(s) not found for architecture x86_64

My configure options are below.  Is there something that needs to be changed?

./configure                                        \
   CC=/opt/local/bin/gcc-mp-4.8                           \
   CFLAGS="-pipe -O2 -m64"                                \
   CPPFLAGS="-D_THREAD_SAFE -I/opt/local/include"         \
   LDFLAGS="-L/opt/local/lib -m64 "                       \
   CXX=/opt/local/bin/g++-mp-4.8                          \
   CXXFLAGS="-pipe -O2 -m64"                              \
   F77=/opt/local/bin/gfortran-mp-4.8                     \
   FFLAGS="-pipe -O2 -m64"                                \
   LLVM_CONFIG=/opt/local/bin/llvm-config-mp-3.3          \
   --with-lapack="-llapack -latlas -lgfortran"            \
   --with-blas="-lcblas -lf77blas -latlas -lgfortran"     \
   --prefix=/opt/octave/3.7                               \
   --enable-gui                                           \
   --disable-jit                                          \
   --disable-java                                         \
   --with-framework-carbon                                \
   --with-arpack                                          \
   --enable-docs                                          \
   --with-opengl                                          \
   --without-x

Ben Abbott <bpabbott>
Project Member
Thu 23 Jan 2014 10:43:16 PM UTC, comment #9: 

I applied patch2.diff, with some indentation cleanup, in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/c460566106f0).  I applied it to the stable branch so it will be a part of the 3.8.1 release.

I'm marking this report as ready-to-test since none of the regular developers have a Mac to see if this change is working with the rest of the changes made for 3.8.1.

Rik <rik5>
Project Administrator
Wed 15 Jan 2014 06:56:14 PM UTC, comment #8: 

So I've determined that --enable-link-all-dependencies solves the issue with libtool. Thus with a patch like this, and that flag set, the Qt build proceeds automatically.

I don't know if y'all think it is OK for ./configure to forcibly enable this flag in this particular scenario, but just in case you don't mind, I've uploaded a new patch that does all that. This new patch uses --libs-only-other per Jordi's suggestion, and it only overrides --enable-link-all-dependencies if 1) you're on Darwin and 2) an -F flag was required to locate the Qt framework.

In the process of testing this I found an error in src/Makefile.am, a backslash was missing.

Anyway, patch2.diff has the goods.

(file #30280)

Michael C. Grant <mcgrant>
Wed 15 Jan 2014 04:03:36 PM UTC, comment #7: 

Argh, that's not enough. Libtool is a problem too. I actually knew that---indeed, when I first submitted this patch, I forgot that I was still using a patched libtool. I've been trying to see if the problem could be corrected solely from within configure, but it seems it can't.

Everything is fine when the GUI libraries are built and linked. The problem is that libtool doesn't know that "-F/usr/local/Cellar/qt/4.8.5/lib" or its "-Wl,-F" equivalent is something that needs to be propagated as a dependency. As a result, the final link doesn't get to see these flags.

Interestingly, the "-Wl,-framework -Wl,Carbon" flags aren't being propagated either, but that's not proving to be a problem, I presume because Carbon is not in fact being used.

So basically, libtool also has to be patched so that it can propagate -F flags the same way it propagates -L flags. It already does the right thing with "-framework" arguments, which is why we haven't seen this before. It's only for non-system frameworks (rather, frameworks not installed on the system path) where this becomes an issue.

I do have a patch for libtool, too, and I'm in conversation with them. They're open to including it, but in the meanwhile, it might be worthwhile to use a fixed libtool script.

Michael C. Grant <mcgrant>
Wed 15 Jan 2014 03:24:05 PM UTC, comment #6: 

I hear you. :-(

I've submitted a bug report to the pkg-config folks as well. The problem is that there is no consensus on what to do. "--libs-only-L" and "--libs-only-l" seem like the logical places to put the "-F" and "-framework" flags, respectively. The upside is that this should naturally make most existing configure scripts work. Others think those need to stay pure and new flags should be added.

I'm in favor of the first idea above.

Michael C. Grant <mcgrant>
Wed 15 Jan 2014 03:16:32 PM UTC, comment #5: 

Sigh, I wish Apple hadn't decided to create their own idiosyncratic linker flags.

What about pkg-config, perhaps that should have an Apple-specific patch too?

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 15 Jan 2014 03:13:56 PM UTC, comment #4: 

Oh, and note the additional "sed 's@^-F@-Wl,-F@'" in there. It turns out most libtool installations won't pass that "-F" flag to the linker unless you escape it like this. I'm actually proposing a patch to the libtool folks about this but I'm now testing to see if tis escaping will solve the problem for us without modifying libtool.

Michael C. Grant <mcgrant>
Wed 15 Jan 2014 03:12:30 PM UTC, comment #3: 

Even if we agree this is the right patch, hold off---I had to learn the ins and outs of M4 quadrigraphs here to get this to parse right with autoconf. A new patch is forthcoming.

To answer your question: I considered that, of course. But it would still require that I perform the same kind of splitting that I'm doing here. The result, it seems to me, would be would look something like this:

    QT_LDFLAGS="`$PKG_CONFIG --libs-only-L QtCore QtGui QtNetwork`"
    QT_LIBS="`$PKG_CONFIG --libs-only-l QtCore QtGui QtNetwork`"
    case $host_os in
    *darwin*)
      QT_LDFLAGS+=" `$PKG_CONFIG --libs-only-other QtCore QtGui QtNetwork | tr ' ' '\n' | grep -e '-@<:@FL@:>@' | uniq | sed 's@^-F@-Wl,-F@' | tr '\n' ' '`"
      QT_LIBS+=" `$PKG_CONFIG --libs-only-other QtCore QtGui QtNetwork | tr ' ' '\n' | grep -v -e '-@<:@FL@:>@' | uniq | tr '\n' ' '`"
      ;;
    *)
      ;;
    esac

(I just did this off the top of my head; I didn't actually test it.) Seems to me it doesn't matter either way.

Michael C. Grant <mcgrant>
Wed 15 Jan 2014 03:08:36 PM UTC, comment #2: 

How about using --libs-only-other instead?

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Wed 15 Jan 2014 06:06:16 AM UTC, comment #1: 

Oops, added the modified file instead of the patch. Here's the patch.

(file #30279)

Michael C. Grant <mcgrant>
Wed 15 Jan 2014 06:05:51 AM UTC, original submission:  

I'm offering a slight modification here to configure.ac that enables it to locate Qt libraries when 1) installed as frameworks instead of a standard library set, and 2) installed in a non-standard location, as is the case with Homebrew.

The proper linker flags for my installation of Qt, for instance, is

-F/usr/local/Cellar/qt/4.8.5.lib -framework QtCore -framework QtGui -framework QtNetwork

but the pkg-config commands in configure will never actually spit out those flags, so QT_LDFLAGS and QT_LIBS remain blank, and the library is not used.

This corrects that limitation by changing the way pkg-config is called for Qt. I am using a case statement here so that the change only applies to Darwin.

Michael C. Grant <mcgrant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #30529:  macgui.diff added by mcgrant (2KiB - application/octet-stream)
file #30357:  patch-config.diff added by mcgrant (1KiB - application/octet-stream)
file #30280:  patch2.diff added by mcgrant (1KiB - application/octet-stream)
file #30279:  patch.diff added by mcgrant (929B - application/octet-stream)
file #30278:  configure.ac added by mcgrant (97KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by mcgrant (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-03-27 mtmiller Dependencies- => bugs #41133 is dependent
    2014-02-12 mcgrant Attached File- => Added macgui.diff, #30529
    2014-01-24 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2014-01-24 mcgrant Attached File- => Added patch-config.diff, #30357
    2014-01-23 rik5 StatusNone => Ready For Test
    2014-01-15 mcgrant Attached File- => Added patch2.diff, #30280
    2014-01-15 mcgrant Attached File- => Added patch.diff, #30279
    2014-01-15 mcgrant Attached File- => Added configure.ac, #30278

    Back to the top


    Powered by Savane 3.5