source-highlight @3.1.8_4+universal: Undefined symbols for architecture i386

[rpspringuel (Br. Samuel Springuel)]

I attempted to upgrade from source-highlight 3.1.8_2 to 3.1.8_4 today and encountered a build error (command execution failed). Attached is the log.

[mf2k (Frank Schima)]

Error is:

:info:build libtool: link: /usr/bin/clang++ -pipe -Os -stdlib=libc++ -arch x86_64 -arch i386 -Wl,-headerpad_max_install_names -stdlib=libc++ -arch x86_64 -arch i386 -o .libs/source-highlight-settings source-highlight-settings.o  -L/opt/local/lib ../gl/.libs/libgnu.a ../lib/srchilite/.libs/libsource-highlight.dylib -lboost_regex-mt
:info:build Undefined symbols for architecture i386:
:info:build   "srchilite::Settings::readDataDir()", referenced from:
:info:build       _main in source-highlight-settings.o
:info:build   "srchilite::Settings::retrieveDataDir(bool)", referenced from:
:info:build       _main in source-highlight-settings.o
:info:build   "srchilite::Settings::checkForConfFile()", referenced from:
:info:build       _main in source-highlight-settings.o
:info:build   "srchilite::Settings::checkForTestFile()", referenced from:
:info:build       checkForTestFile() in source-highlight-settings.o
:info:build   "srchilite::Settings::save()", referenced from:
:info:build       save() in source-highlight-settings.o
:info:build   "srchilite::Settings::Settings()", referenced from:
:info:build       __GLOBAL__sub_I_source_highlight_settings.cpp in source-highlight-settings.o
:info:build   "srchilite::Settings::~Settings()", referenced from:
:info:build       __GLOBAL__sub_I_source_highlight_settings.cpp in source-highlight-settings.o
:info:build   "srchilite::Versions::getCompleteVersion()", referenced from:
:info:build       _main in source-highlight-settings.o
:info:build ld: symbol(s) not found for architecture i386
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)

[kencu (Ken)]

looks like you're trying to build it +universal, and some of the parts have not been built that way. There's probably no reason to build it +universal, I would say. Why don't you try building it without universal, possibly forcing that choice by -universal, and see if it's happier that way.

Either that, or see if you find out which things are build +universal, and which are not, and fix the ones that are not +universal.

[rpspringuel (Br. Samuel Springuel)]

So after studying my installation trying to figure out where the non-universal dependency was, I discovered that source-highlight itself was a 2nd-level leave for me, not a dependency. At some point I must have installed something that depended on gtk-doc (and which probably invoked the +universal variant), but whatever it was, I don't have it installed any more. As a result I've just removed the leave. If I find the time I'll go back and try and figure out the problem further, but since I don't actually need it, and I have a whole lot of other things on my plate, that might take a while.

[ryandesign (Ryan Schmidt)]

We can see in the log that this line is invoking the compiler without specifying the necessary -arch and -stdlib flags:

:info:build libtool: link: /usr/bin/clang++ -r -keep_private_externs -nostdlib -o .libs/libsource-highlight.4.dylib-master.o  .libs/fileutil.o .libs/substfun.o .libs/stopwatch.o .libs/utils.o .libs/ioexception.o .libs/settings.o .libs/versions.o .libs/verbosity.o .libs/sourcehighlight.o .libs/styleparser.o .libs/stylescanner.o .libs/outlangdefparser.o .libs/stylecssparser.o .libs/stylecssscanner.o .libs/outlangdefscanner.o .libs/debuglistener.o .libs/langmap.o .libs/stylefileparser.o .libs/langelem.o .libs/statelangelem.o .libs/langelems.o .libs/statestartlangelem.o .libs/stringlistlangelem.o .libs/delimitedlangelem.o .libs/langelemsprinter.o .libs/namedsubexpslangelem.o .libs/stringdef.o .libs/highlightrule.o .libs/highlighttoken.o .libs/highlightstate.o .libs/highlightrulefactory.o .libs/highlightstateprinter.o .libs/sourcehighlighter.o .libs/sourcefilehighlighter.o .libs/linenumgenerator.o .libs/lineranges.o .libs/regexranges.o .libs/formatter.o .libs/formattermanager.o .libs/textstyle.o .libs/textstyleformatter.o .libs/bufferedoutput.o .libs/preformatter.o .libs/wordtokenizer.o .libs/ctagscollector.o .libs/readtags.o .libs/ctagsformatter.o .libs/srcuntabifier.o .libs/textstyleformatterfactory.o .libs/docgenerator.o .libs/doctemplate.o .libs/chartranslator.o .libs/textstylebuilder.o .libs/fileinfo.o .libs/ctagsmanager.o .libs/regexhighlightrule.o .libs/regexrulefactory.o .libs/regexpreprocessor.o .libs/highlightstatebuilder.o .libs/highlightbuilderexception.o .libs/langdefmanager.o .libs/langdefparser.o .libs/langdefscanner.o .libs/languageinfer.o .libs/parserexception.o .libs/stringtable.o .libs/vardefinitions.o .libs/sourcehighlightutils.o .libs/instances.o .libs/yywrap.o   .libs/libsource-highlight.lax/libgnu.a/basename-lgpl.o .libs/libsource-highlight.lax/libgnu.a/dirname-lgpl.o .libs/libsource-highlight.lax/libgnu.a/getopt.o .libs/libsource-highlight.lax/libgnu.a/getopt1.o .libs/libsource-highlight.lax/libgnu.a/progname.o .libs/libsource-highlight.lax/libgnu.a/stripslash.o

[Ionic (Mihai Moldovan)]

We can see in the log that this line is invoking the compiler without specifying the necessary -arch and -stdlib flags:

The -stdlib flag shouldn't be necessary. Note that this call is merely merging multiple object files into one big one (and skipping linking against other libraries, including a standard library, explicitly via -nostdlib).

It's questionable why libtool would link individual object files into a big one prior to creating the dylib, but we'll have to live with that behavior.

Creating object files with -r and without -arch flags will however only leave default-arch symbols in the resulting thin object file - exactly what is happening here.

The question thus is why libtool is dropping -arch flags from this linking call only. It does use -arch flags for other link operations, so it's unlikely to be caused by its intentional dropping of unknown LDFLAGS.

Changing to the muniversal PortGroup likely won't help either, since the i386 build objects would likewise be dropped within the i386 build process.

[jmroot (Joshua Root)]

Can you please see if [17ff20b97ea77403492e1bad7beb153f0e6c8312/macports-ports] has helped with this?

[jmroot (Joshua Root)]

Confirmed fixed by another affected user on IRC.