Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#32552 closed defect (duplicate)

Mesa 7.11 does not compile on Tiger/Mac OS X 10.4.11 because unsupported platform

Reported by: ballapete (Peter Dyballa) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia)
Port: Mesa

Description

Hello!

While updating my "saved" Tiger installation, PPC, this failure happened:

/usr/bin/gcc-4.0 -I/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/mesa/files/include -c -o state_tracker/st_atom_constbuf.o state_tracker/st_atom_constbuf.c  -D_DARWIN_C_SOURCE -DPTHREADS -D_GNU_SOURCE -DGLX_ALIAS_UNSUPPORTED -DGLX_DIRECT_RENDERING -DGLX_USE_APPLEGL -I../../include -I../../src/glsl -I../../src/mesa -I../../src/mapi -I../../src/gallium/include -I../../src/gallium/auxiliary  -ggdb3 -Os -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fno-common -fvisibility=hidden -I/opt/local/include -I/opt/local/include -fPIC -arch ppc
In file included from ../../src/gallium/auxiliary/util/u_inlines.h:38,
                 from state_tracker/st_atom_constbuf.c:40:
../../src/gallium/auxiliary/util/u_atomic.h:37:2: error: #error "Unsupported platform"
../../src/gallium/auxiliary/util/u_atomic.h:347:2: error: #error "No pipe_atomic implementation selected"
In file included from state_tracker/st_atom_constbuf.c:40:
../../src/gallium/auxiliary/util/u_inlines.h: In function ‘pipe_reference_init’:
../../src/gallium/auxiliary/util/u_inlines.h:56: warning: implicit declaration of function ‘p_atomic_set’
../../src/gallium/auxiliary/util/u_inlines.h: In function ‘pipe_is_referenced’:
../../src/gallium/auxiliary/util/u_inlines.h:62: warning: implicit declaration of function ‘p_atomic_read’
../../src/gallium/auxiliary/util/u_inlines.h: In function ‘pipe_reference_described’:
../../src/gallium/auxiliary/util/u_inlines.h:82: warning: implicit declaration of function ‘p_atomic_inc’
../../src/gallium/auxiliary/util/u_inlines.h:88: warning: implicit declaration of function ‘p_atomic_dec_zero’
make[2]: *** [state_tracker/st_atom_constbuf.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_mesa/mesa/work/Mesa-7.11/src/mesa'

Attachments (1)

main.log (414.7 KB) - added by ballapete (Peter Dyballa) 9 years ago.
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_mesa/mesa/main.log

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by ballapete (Peter Dyballa)

Attachment: main.log added

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_mesa/mesa/main.log

comment:1 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: wontfix
Status: newclosed

That's supposed to be handled by this hunk in the Portfile:

        # http://trac.macports.org/ticket/24345
        # http://trac.macports.org/ticket/24393
        # http://trac.macports.org/ticket/29860
        if {${build_arch} == "ppc"} {
            reinplace "/SRC_DIRS/ s/gallium//" ${worksrcpath}/configs/darwin
        }       

If you figure out why that's not working and can provide a patch, I'll commit it, but I don't even use Leopard any more let alone Tiger.

comment:2 in reply to:  1 Changed 9 years ago by ballapete (Peter Dyballa)

When I start port it shows some suspicious lines because the previous version of mesa was built as some variant:

DEBUG: epoch: in tree: 1 installed: 0
DEBUG: mesa 7.11_2 exists in the ports tree
DEBUG: mesa 7.6_1 +darwin_8+hw_render is the latest installed
DEBUG: mesa 7.6_1 +darwin_8+hw_render is active
DEBUG: Merging existing variants '+darwin_8+hw_render' into variants
DEBUG: new fully merged portvariants: darwin_8 + hw_render +
DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/mesa
DEBUG: OS darwin/8.11.0 (Mac OS X 10.4) arch powerpc
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Requested variant darwin_8 is not provided by port mesa.
DEBUG: Requested variant hw_render is not provided by port mesa.
DEBUG: Executing variant python27 provides python27

If that's not the cause for the failure, is there some way to make the "execution of the Portfile" visible as in sh -vx <some script>?

Can it be that file "darwin" in ${worksrcpath}/configs, i.e. /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_mesa/mesa/work/Mesa-7.11/configs, is the wrong target for the substitution because the file "default" is used for compilation? The file "darwin" does not contain a single occurrence of the word "gallium". It is up-to-date, i.e., it has a time stamp from time when I invoked port. There also a sym-link "current -> darwin" exists.

Another suspicious line is this one:

:debug:build Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_mesa/mesa/work/Mesa-7.11" && /usr/bin/make -w default INSTALL_DIR=/opt/local RC_CFLAGS="-arch ppc" CC="/usr/bin/gcc-4.0 -I/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/mesa/files/include" CXX="/usr/bin/g++-4.0 -I/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/mesa/files/include" PYTHON2="/opt/local/bin/python2.7"'

Shouldn't the MAKE target be "current" or better "darwin"? I made that change in Portfile (line #57) right now, but nothing has changed. And I am going to bed now... Maybe the result will be different in the morning!

comment:3 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Yes, that should be darwin ... r88037

comment:4 Changed 9 years ago by ryandesign (Ryan Schmidt)

Resolution: wontfix
Status: closedreopened

comment:5 Changed 9 years ago by ryandesign (Ryan Schmidt)

Resolution: duplicate
Status: reopenedclosed

Duplicate of #29860.

comment:6 in reply to:  3 Changed 9 years ago by ballapete (Peter Dyballa)

Replying to jeremyhu@…:

Yes, that should be darwin ... r88037

Right now, around 10:30 UTC, after a selfupdate half an hour ago, I have:

3350046   16 -rw-r--r--    1 root     admin        5247 7 Dez 01:28 rsync.macports.org/release/ports/x11/mesa/Portfile
3152620   16 -rw-r--r--    1 root     wheel        5248 5 Okt 19:30 rsync.macports.org/release/tarballs/ports/x11/mesa/Portfile

diff rsync.macports.org/release/ports/x11/mesa/Portfile rsync.macports.org/release/tarballs/ports/x11/mesa/Portfile
57c57
< build.target darwin
---
> build.target default

I was looking and then editing the latter, which is now "up-to-date" again. From 'port -vd clean mesa' I can see again that probably the latter Portfile is used for the build:

DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/x11/mesa

Why do these two almost identical Portfiles exist? Is there no way to remove the useless variants?

Anyway, 3 h laters, although the target "darwin" was made, I am back at the previous failure, just as in #29860 described. OK! I'll have to have a closer look later!

Note: See TracTickets for help on using tickets.