Opened 5 years ago

Last modified 5 years ago

#59104 assigned defect

recoll: not using the right compiler and ignoring stdlib in link stage

Reported by: mojca (Mojca Miklavec) Owned by: medoc9
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Port: recoll

Description

Accoding to https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/45/steps/install-port/logs/stdio:

The build fails in linking stage for at least two reasons:

  • It's not using the right compiler
  • The -stdlib=libc++ doesn't end up in linking command
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o recoll.app/Contents/MacOS/recoll .obj/advsearch_w.o .obj/advshist.o .obj/confgui.o .obj/confguiindex.o .obj/crontool.o .obj/fragbuts.o .obj/guiutils.o .obj/main.o .obj/multisave.o .obj/preview_load.o .obj/preview_plaintorich.o .obj/preview_w.o .obj/ptrans_w.o .obj/rclhelp.o .obj/rclm_idx.o .obj/rclm_preview.o .obj/rclm_saveload.o .obj/rclm_view.o .obj/rclm_wins.o .obj/rclmain_w.o .obj/rclzg.o .obj/reslist.o .obj/respopup.o .obj/restable.o .obj/rtitool.o .obj/searchclause_w.o .obj/snippets_w.o .obj/spell_w.o .obj/ssearch_w.o .obj/systray.o .obj/uiprefs_w.o .obj/viewaction_w.o .obj/webcache.o .obj/qxtconfirmationmessage.o .obj/xmltosd.o .obj/qrc_recoll.o .obj/moc_advsearch_w.o .obj/moc_confgui.o .obj/moc_confguiindex.o .obj/moc_crontool.o .obj/moc_firstidx.o .obj/moc_fragbuts.o .obj/moc_idxsched.o .obj/moc_preview_load.o .obj/moc_preview_plaintorich.o .obj/moc_preview_w.o .obj/moc_ptrans_w.o .obj/moc_rclhelp.o .obj/moc_restable.o .obj/moc_rtitool.o .obj/moc_searchclause_w.o .obj/moc_snippets_w.o .obj/moc_specialindex.o .obj/moc_spell_w.o .obj/moc_ssearch_w.o .obj/moc_systray.o .obj/moc_uiprefs_w.o .obj/moc_viewaction_w.o .obj/moc_webcache.o .obj/moc_editdialog.o .obj/moc_listdialog.o .obj/moc_qxtconfirmationmessage.o   -F/opt/local/libexec/qt5/lib -L../.libs -lrecoll -L/opt/local/lib -lxapian  -liconv -R/opt/local/lib  -lz -framework QtWebKitWidgets -framework QtWebKit -framework QtGui -framework QtCore -framework DiskArbitration -framework IOKit -L/opt/local/lib/openssl-1.0 -framework QtNetwork -framework QtWidgets -framework QtPrintSupport -framework QtXml -framework OpenGL -framework AGL 
clang: warning: argument unused during compilation: '-R/opt/local/lib'
Undefined symbols for architecture x86_64:
  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(char const*) const", referenced from:
      forgetTempFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) in main.o
      Preview::loadDocInCurrentTab(Rcl::Doc const&, int) in preview_w.o
      RclMain::saveLastQuery() in rclm_saveload.o
      RclMain::startNativeViewer(Rcl::Doc, int, QString) in rclm_view.o
      RclMain::onSortDataChanged(DocSeqSortSpec) in rclmain_w.o
      ResultPopup::create(QWidget*, int, std::__1::shared_ptr<DocSequence>, Rcl::Doc&) in respopup.o
      Rcl::Doc::isFsFile() in respopup.o
      ...
  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(unsigned long, unsigned long, char const*) const", referenced from:
      Preview::loadDocInCurrentTab(Rcl::Doc const&, int) in preview_w.o
  "std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::compare(unsigned long, unsigned long, char const*, unsigned long) const", referenced from:
      PrefsPack::stemlang() in guiutils.o
      _main in main.o
      ResList::menuPreviewParent() in reslist.o
      ResTable::menuPreviewParent() in restable.o
  "std::__1::__vector_base_common<true>::__throw_length_error() const", referenced from:
      void std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__push_back_slow_path<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&&&) in advsearch_w.o
      void std::__1::vector<int, std::__1::allocator<int> >::__push_back_slow_path<int>(int&&) in advsearch_w.o
      void std::__1::vector<SearchClauseW*, std::__1::allocator<SearchClauseW*> >::__push_back_slow_path<SearchClauseW* const&>(SearchClauseW* const&&&) in advsearch_w.o
      std::__1::vector<std::__1::shared_ptr<Rcl::SearchData>, std::__1::allocator<std::__1::shared_ptr<Rcl::SearchData> > >::insert(std::__1::__wrap_iter<std::__1::shared_ptr<Rcl::SearchData> const*>, std::__1::shared_ptr<Rcl::SearchData> const&) in advshist.o
      void std::__1::vector<RclSListEntry, std::__1::allocator<RclSListEntry> >::__push_back_slow_path<RclSListEntry const&>(RclSListEntry const&&&) in advshist.o
      void std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::__push_back_slow_path<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&&&) in advshist.o
      void std::__1::vector<std::__1::shared_ptr<Rcl::SearchData>, std::__1::allocator<std::__1::shared_ptr<Rcl::SearchData> > >::__push_back_slow_path<std::__1::shared_ptr<Rcl::SearchData> const&>(std::__1::shared_ptr<Rcl::SearchData> const&&&) in advshist.o

I suspect this might be Qt5's fault, but I'm not sure.

Change History (3)

comment:1 Changed 5 years ago by kencu (Ken)

I fixed all the macports-clang-* versions to default to -stdlib=libc++ if macports was configured to use libc++.

But the ancient rickety old clangs on 10.7 and 10.8 don't know about that, so they still default to the old -stdlib=libstdc++ if they don't see otherwise on the build line.

So now we're going to see that on 10.7 and 10.8 like we used to see that on 10.6.8 until I fixed it.

This would be a significant regression to go back and fix each individual port. I know it's the right thing to do, -- but nobody is going to do it, certainly not me at this point in time.

I would say when we see this, just blacklist the old clangs on 10.7 and 10.8 (whatever 10.9 is fine) and then a macports clang compiler will be called in, and it will do the right thing.

Or change the defaulting to macports-clang-5.0+ on 10.7 and 10.8, if that is acceptable. Nobody cares if the old apple clangs in 10.7 and 10.8 can build a port any longer....

Last edited 5 years ago by kencu (Ken) (previous) (diff)

comment:2 Changed 5 years ago by mojca (Mojca Miklavec)

Except that blacklisting won't help in this particular case, since the port is not respecting the compiler choice in all the steps. The port is already using clang-8.0, just not during linking.

(I probably agree with the rest, it just doesn't apply to this port.)

comment:3 Changed 5 years ago by kencu (Ken)

Ah, you are exactly right, I did not notice that detail.

Some of how the linker is called is determined by the qmake5 portgroup stuff Marcus wrote up -- I got into that when I ported qt53 to 10.6.8 -- so it might be profitable to look at that. I assume that is being called in for at least some of this.

Note: See TracTickets for help on using tickets.