Opened 5 years ago

Closed 12 months ago

Last modified 12 months ago

#47944 closed defect (wontfix)

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

Reported by: ryandesign (Ryan Schmidt) Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: Cc:
Port: poppler

Description

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?

Attachments (1)

main.log.bz2 (17.2 KB) - added by ryandesign (Ryan Schmidt) 5 years ago.

Download all attachments as: .zip

Change History (6)

Changed 5 years ago by ryandesign (Ryan Schmidt)

Attachment: main.log.bz2 added

comment:1 Changed 5 years ago by 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?

comment:2 Changed 5 years ago by ryandesign (Ryan 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.

Last edited 5 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:3 in reply to:  description Changed 5 years ago by 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?

comment:4 Changed 5 years ago by ryandesign (Ryan 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.

comment:5 Changed 12 months ago by kencu (Ken)

Resolution: wontfix
Status: newclosed

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.

Last edited 12 months ago by kencu (Ken) (previous) (diff)
Note: See TracTickets for help on using tickets.