mesa-7.8.1 on Tiger PPC: Unsupported platform, No pipe_atomic implementation selected

[emily@…]

Build again fails on Mac OS X 10.4.11 (PPC) XCode 2.5, but much farther along the build process than before.

[jmroot (Joshua Root)]

Please remember to cc the maintainer.

[jeremyhu (Jeremy Huddleston Sequoia)]

This should be handled by not building gallium:

        # http://trac.macports.org/ticket/24345
        reinplace "/SRC_DIRS/ s/gallium//" ${worksrcpath}/configs/darwin

If you can figure out why it's not building and supply me with a patch, I'll use it, but Tiger is not supported any more. Hopefully someone else will figure out what is going on here.

[emily@…]

Replying to jeremyhu@…:

This should be handled by not building gallium:

        # http://trac.macports.org/ticket/24345
        reinplace "/SRC_DIRS/ s/gallium//" ${worksrcpath}/configs/darwin

If you can figure out why it's not building and supply me with a patch, I'll use it, but Tiger is not supported any more. Hopefully someone else will figure out what is going on here.

The build still fails with the same errors.

[luis.beca@…]

Mesa 7.8.1_1 fails to build on Snow Leopard (on an iMac9,1) but succeeds on a MacbookPro1,1.

[jeremyhu (Jeremy Huddleston Sequoia)]

luis, that is a different build failure. Please open a different ticket.

[yaseppochi (Stephen J. Turnbull)]

Replying to jeremyhu@…:

This should be handled by not building gallium:

        # http://trac.macports.org/ticket/24345
        reinplace "/SRC_DIRS/ s/gallium//" ${worksrcpath}/configs/darwin

If you can figure out why it's not building and supply me with a patch

I don't know why that doesn't work, but it doesn't: port tries to build gallium anyway. I tried also removing gallium from default and current in ${worksrcpath/configs/}, but those changes didn't help either.

The patch I'm about to upload does permit building, but I have no idea if it's correct or not. I don't understand why this port builds anywhere, I can't figure out where the flags necessary to #include that file and not run into the "unsupported platform" error are getting #defined'd.

[ryandesign (Ryan Carsten Schmidt)]

I think the issue is Tiger PPC specific -- it builds fine for me an Leopard PPC and Tiger Intel but not Tiger PPC.

[ryandesign (Ryan Carsten Schmidt)]

Replying to stephen@…:

The patch I'm about to upload does permit building, but I have no idea if it's correct or not.

Your patch uses PIPE_ATOMIC_GCC_INTRINSIC if no other methods were found to work. But the code was deliberately changed upstream to ​only use PIPE_ATOMIC_GCC_INTRINSIC if GCC 4.1 or greater is found, and Leopard and Tiger come with GCC 4.0.1, so I would not be comfortable second-guessing them on this decision. The commit message does not explain why this change was made; we could ask the author of the change for more information.

I don't understand why this port builds anywhere,

I haven't analyzed the source code in any great detail, but with a little testing I found that on Tiger Intel, it uses PIPE_ATOMIC_ASM_GCC_X86; on Snow Leopard (where GCC 4.2.1 is the default), it uses PIPE_ATOMIC_GCC_INTRINSIC; and on Leopard PPC it also uses PIPE_ATOMIC_GCC_INTRINSIC, thanks to the change in r65971 that makes the port use Leopard's Xcode's optional GCC 4.2.1.

One possible solution this information leads us to is using a MacPorts GCC port (gcc45, gcc44, etc.) for mesa on Tiger PowerPC. That would have implications for building universal, but not if we use the compiler in the apple-gcc42 port. And it's a heavy dependency in that the GCC ports take a long time to build, especially for older slower PowerPCs, which are exactly the set of Macs affected by the problem. :/

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

not if we use the compiler in the apple-gcc42 port.

Except that apple-gcc42 doesn't build on Tiger PPC.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

the code was deliberately changed upstream to ​only use PIPE_ATOMIC_GCC_INTRINSIC if GCC 4.1 or greater is found

Couple this with the fact that the code was deliberately changed to ​remove the PIPE_ATOMIC_MUTEX fallback that had been in place if all else failed, with the only explanation that they wanted to "severe [sic] the dependency in [sic] OS abstractions from the Gallium interfaces".

[yaseppochi (Stephen J. Turnbull)]

*sigh*

I agree with your reasoning throughout, but as Rhett said to Scarlett, "Frankly, my dear, I don't give a damn." I didn't ask for Mesa, I don't know why it gets built. If I could trust port's dependency graph (which unfortunately I can't, I've dealt with at least one port recently which has a dependency cycle, so some maintainer just broke the cycle by ignoring the dependency), I'd say it's getting pulled in as a prerequisite for xorg-libs, which is a prerequisite for ImageMagick, which is a prerequisite for inkscape ("yes, officer, I did deliberately install inkscape"). But for exe in `port contents ImageMagick | grep 'lib\|bin'`; do otool -L $exe | grep -i mesa; done says nothing in ImageMagick seems to link to Mesa! In fact nothing in my MacPorts installation does. :-(

So I find it hard to care about whether general approach in the patch is correct. :-(

[ryandesign (Ryan Carsten Schmidt)]

This ticket is about getting mesa 7.8.1 to build on Tiger PPC. If your complaint is that mesa should be removed as a dependency from some port, then that's a separate matter to be filed as a separate ticket. However, according to port_rdeps, mesa is not in the dependency graph for inkscape -- at least, not with the default variants. Perhaps you have selected a different variant of some port that is pulling in mesa, though there aren't that many ports that depend on mesa. The most likely one I see is xorg-server. The files installed by xorg-server don't dynamically link to any library provided by mesa (according to otool -L) but mesa is only a build dependency of xorg-server and not a library dependency.

[jeremyhu (Jeremy Huddleston Sequoia)]

The mesa port should not even be building these bits on Tiger because of this:

reinplace "/SRC_DIRS/ s/gallium//" ${worksrcpath}/configs/darwin

Is that not getting applied for some reason, or is mesa still trying to build gallium even though it's told not to?

[ryandesign (Ryan Carsten Schmidt)]

The reinplace is being applied correctly. "gallium" gets correctly removed from configs/darwin. But the gallium headers are still being included from elsewhere in the project. In this case, it's compiling src/mesa/state_tracker/st_atom_constbuf.c, which has a #include "util/u_inlines.h", which is in fact src/gallium/auxiliary/util/u_inlines.h.

[jeremyhu (Jeremy Huddleston Sequoia)]

ok. then punting those bits from Tiger, too.

r66677

[jeremyhu (Jeremy Huddleston Sequoia)]

Emily said this is still happening... I fail to see how since it should not be building that code any more.

Did you 'sudo port selfupdate' ? Can you try again since you might not have gotten the update.

[ryandesign (Ryan Carsten Schmidt)]

Yes, the error is the same, though now it's occurring in the destroot phase. Seems the build phase now knows to skip building it, but the destroot phase doesn't know that.

make[3]: *** [state_tracker/st_atom_constbuf.o] Error 1
make[2]: *** [install_libraries] Error 2
make[1]: *** [install] Error 1
make: *** [install] Error 1
Error: Target org.macports.destroot returned: shell command " cd "/mp/var/macports/build/_Volumes_data_macports_ports_x11_mesa/work/Mesa-7.8.1" && /usr/bin/make install INSTALL_DIR=/mp DESTDIR=/mp/var/macports/build/_Volumes_data_macports_ports_x11_mesa/work/destroot " returned error 2

[jeremyhu (Jeremy Huddleston Sequoia)]

weird...

[yaseppochi (Stephen J. Turnbull)]

Replying to ryandesign@…:

This ticket is about getting mesa 7.8.1 to build on Tiger PPC. If your complaint is that mesa should be removed as a dependency from some port,

No, I'm simply suggesting that unless Mesa is actually used for something by somebody, it doesn't matter if the patch is /functional/, as long as it /builds/. Since Tiger isn't supported any more, I don't see that you really need to care.

[jeremyhu (Jeremy Huddleston Sequoia)]

Mesa is actually used ;) ... it should build on tiger without the gallium bits. I'm still confused as to why it is failing (especially in install...) hopefully ryan can figure that out since I don't have Tiger/ppc and don't have the time to dive into this at the moment.

[erks@…]

Cc Me!

[touch.ung@…]

Cc Me!

[erks@…]

Cc Me!

[benjamin.a.lau@…]

Replying to jeremyhu@…:

weird...

I was running into this bug and decided to hunt it down. I found a hand fix that seems to do the trick... but I've only been using MacPorts for about 4 days and have no experience with the FreeBSD ports system (I'm normally a Debian user and had been using Fink until a few days ago). Anyway here's a patch to the Mesa-7.8.1/src/mesa/sources.mak that seems to correct the issue and hopefully that'll be enough of a clue that somebody who knows this stuff can fix this bug properly. :-)

 -u sources.mak.orig sources.mak
--- sources.mak.orig    2010-05-24 03:04:48.000000000 -0700
+++ sources.mak 2010-05-24 03:05:00.000000000 -0700
@@ -354,7 +354,7 @@
        $(MESA_ASM_SOURCES:.S=.o)
 
 MESA_GALLIUM_OBJECTS = \
-       $(MESA_GALLIUM_SOURCES:.c=.o) \
+#      $(MESA_GALLIUM_SOURCES:.c=.o) \
        $(MESA_ASM_SOURCES:.S=.o)
 
 GLAPI_OBJECTS = \

[benjamin.a.lau@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

The problem is that gallium isn't being built in the normal make phase, but it is in the install phase. It's not supported on Tiger/ppc, so it is disabled. We need to figure out why 'make install' is trying to build it...

Unfortunately, the patch you are providing is not really a fix. It just says "when building gallium, stop including these files" whereas we want to say "stop building gallium"

[jeremyhu (Jeremy Huddleston Sequoia)]

Tiger isn't supported, and nobody seems to care about fixing this. Closing.

[yaseppochi (Stephen J. Turnbull)]

Replying to jeremyhu@…:

Tiger isn't supported, and nobody seems to care about fixing this. Closing.

You mean *you* don't care about fixing it. No surprise there. :-(

But several users care, and have submitted patches. And ryandesign added some possibly useful analysis in case some user decides to work on the issue and come up with a correct fix.

At least leave this issue open so that other users will find the patches easily with a simple 16?PORT=mesa query. I only found it because I contributed one of those patches.

[yaseppochi (Stephen J. Turnbull)]

Shows dependencies that need to go to build on Tiger/PPC

[yaseppochi (Stephen J. Turnbull)]

OK, so I think I found the problem, which is the dependencies which are removed in the attached patch mesa_Makefile-gallium-suppression.diff. The patch itself cannot simply be listed in patchfiles in the Portfile, because other platforms use gallium. I don't know how to say "only do this on PPC Tiger" in port-uguese, so I hope someone who speaks that language will fix it up.

I don't understand how those targets were suppressed for the build phase, but "default" is a dependency for some of the install targets, which is why those are getting pulled in at the destroot phase. Perhaps this patch (or some equivalent magic) would serve to inhibit gallium at both the build and install phases.

[wrigleyster@…]

@people who pass here by, and just want xorg-server up and running: installing mesa@63184 : source:/trunk/dports/x11/mesa@63184 and then installing xorg-server with:

sudo port -n install xorg-server

is a winwin.

as for the real topic of the ticket:
I had the same problem.
I installed the macports gcc45, and selected it with gcc_select.
Then there were neither build nor destroot issues.

Cheers!

[ryandesign (Ryan Carsten Schmidt)]

Replying to stephen@…:

OK, so I think I found the problem, which is the dependencies which are removed in the attached patch mesa_Makefile-gallium-suppression.diff

Thanks, that fixes the build on Tiger for me. Committed in r75074.

[cooljeanius (Eric Gallager)]

Cc Me!