poppler @0.33.0: cross-compilation fails: Bad CPU type in executable

[ryandesign (Ryan Carsten Schmidt)]

I need to create a universal binary of poppler that involves cross-compilation. In the case of the attached log, that means building for x86_64 on an i386 Mac, but it would also mean building for ppc64 on a ppc Mac or on any Intel Mac, or for i386 or x86_64 on any PowerPC Mac.

The error is:

Poppler-0.18: Bad CPU type in executable

It appears the poppler build is trying to run something it just compiled, which cannot work when cross-compiling.

This wouldn't be an issue with the normal universal variant, since all architectures would be in the same file, but it is a problem when using the muniversal portgroup, which poppler does, but r50531 doesn't explain why. Maybe it doesn't need to?

[dbevans (David B. Evans)]

Looks like something that I inherited. As you say, muniversal might not be necessary. Is this a just a regular universal build on an i386 machine or are you doing something special?

[ryandesign (Ryan Carsten Schmidt)]

You would not see this with a normal universal build on a 64-bit Intel machine because it can run all the archs it produces. I see the issue because I'm building on a 32-bit machine. I've also added ppc to the universal_archs which should not be a problem (on Snow Leopard or earlier, because it has Rosetta), but I will ultimately want to add ppc64 as well which will be a problem too. You would presumably also see the issue trying to build a normal universal on a PowerPC machine.

Back when muniversal was first introduced Marcus was adding it to ports somewhat at random, for no reason other than muniversal was the new thing and it was thought to be more reliable, but we quickly saw issues with this approach, such as the one I'm bringing up in this ticket. I don't know if muniversal was added to poppler for this (non) reason, or if there was a real reason why the default universal variant didn't work right for poppler, or if so, if that reason still applies with 0.33.0.

[dbevans (David B. Evans)]

Replying to ryandesign@…:

This wouldn't be an issue with the normal universal variant, since all architectures would be in the same file, but it is a problem when using the muniversal portgroup, which poppler does, but r50531 doesn't explain why. Maybe it doesn't need to?

Ryan --

I'm leaving this up to you since you understand the specific case being addressed and have the hardware to test.

Have you been able to verify that removing muniversal solves your problem without breaking the normal universal build?

[ryandesign (Ryan Carsten Schmidt)]

I have not investigated further. My use case is making a distributable binary of Graphviz. Poppler's license is incompatible, making Graphviz undistributable. Therefore I removed poppler support from the default Graphviz build in r138202.

[kencu (Ken)]

poppler now requires c++14 <​https://github.com/macports/macports-ports/blob/d54bb6cced5099258e21ccb57cde2318f7467214/graphics/poppler/Portfile#L57> and we have no compilers that presently can cross-compile intel and PPC code c++14.