clang-11 @11.1.0_7 +universal fails to build when libxslt -universal is active

[fhgwright (Fred Wright)]

It appears that clang-11 (and perhaps other versions as well) has some sort of broken opportunistic build such that the presence of an active libxslt port causes it to build something that fails to link when a needed architecture is missing. No dependency on libxslt is shown.

The clang-11 +universal build succeeds if there's either an active libxslt +universal port or no active libxslt port. Oddly enough, the installed content is the same in both cases, so perhaps it's opportunistically building something that it doesn't actually install.

This was observed in 10.11, but the OS version probably doesn't matter.

I captured logs for both the failing case and the successful case with no active libxslt. I neglected to capture the successful case with the active libxslt +universal, and redoing that would be time-consuming.

[fhgwright (Fred Wright)]

Unfortunately, both logfiles exceed the 10MB limit. Since the problem is probably reproducible under the conditions stated above, I won't bother trying to break them up unless it's necessary.

[jmroot (Joshua Root)]

You can compress the logs with bzip2 or whatever to get them under the attachment size limit.

[fhgwright (Fred Wright)]

Failed build with active libxslt -universal

[fhgwright (Fred Wright)]

Successful build with no active libxslt

[fhgwright (Fred Wright)]

Replying to jmroot:

You can compress the logs with bzip2 or whatever to get them under the attachment size limit.

Done.

[ryandesign (Ryan Carsten Schmidt)]

This sounds like a linker bug we encountered many years ago already. I know of no solution other than installing the offending libraries universal.

[kencu (Ken)]

all the years I’ve been building clang, I’ve never seen this…

I can’t as yet find anywhere that the llvm tree tries to link in libxslt

probably have to run the failing link manually with -Wl,-v to get some idea what is going on here

[fhgwright (Fred Wright)]

Replying to ryandesign:

This sounds like a linker bug we encountered many years ago already. I know of no solution other than installing the offending libraries universal.

I don't see how a linker bug would cause it to optionally link against libxslt. Once it does that, it's of course not a bug that it can't link against a library with a missing architecture.

Replying to kencu:

all the years I’ve been building clang, I’ve never seen this…

I can’t as yet find anywhere that the llvm tree tries to link in libxslt

The log shows the command that's doing it, but not why it's doing it.

probably have to run the failing link manually with -Wl,-v to get some idea what is going on here

I neglected to capture .CC_PRINT_OPTIONS, which might be helpful.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

This sounds like a linker bug we encountered many years ago already.

#36438 is the issue I was thinking of. Per comment:ticket:36438:60 "There's not really anything we can do about this. This is how the toolchain works..." See also my summary in comment:ticket:52337:9 and Jeremy's comment:ticket:52337:19: "It is a bug in the linker. That is <rdar://problem/12450551>, which I filed back in 2012." Using trace mode (sudo port -t install ...) may be another workaround.

[kencu (Ken)]

that is one weird bug… I still don’t quite follow the issue exactly:

“ It's the use of -L/opt/local/lib that is causing ld to resolve the /usr/lib/libstdc++.6.dylib link in an existing library to /opt/local/lib/libstdc++.6.dylib in much the same way that DYLD_LIBRARY_PATH operates at runtime for dyld.”

[fhgwright (Fred Wright)]

Replying to kencu:

that is one weird bug… I still don’t quite follow the issue exactly:

You and me both.

“ It's the use of -L/opt/local/lib that is causing ld to resolve the /usr/lib/libstdc++.6.dylib link in an existing library to /opt/local/lib/libstdc++.6.dylib in much the same way that DYLD_LIBRARY_PATH operates at runtime for dyld.”

I don't see how the linker can be blamed for doing exactly what it's told to do, which is to use /opt/local/lib/libstdc++.6.dylib in preference to /usr/lib/libstdc++.6.dylib, and which expectedly fails when trying to link something universal against a non-universal library. IMO, those tickets were misdiagnosed and prematurely closed as wontfix.

In any case, that's not the same situation as the one here. That one involves expectedly linking against a library which has been overridden by a non-universal build, while this one involves unexepectedly linking against a library which is not considered to need to be universal since it's not an expected dependency.

The question here is why libxslt is being used at all.