Opened 7 weeks ago

Closed 5 weeks ago

#62063 closed defect (fixed)

mesa @19.0.8_0+osmesa+python27 patch failure on 10.6

Reported by: rmottola (Riccardo) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: patch snowleopard Cc: rlhamil, ballapete (Peter Dyballa), macportsraf
Port: mesa

Description

:info:patch Hunk #1 succeeded at 450 (offset -68 lines).
:info:patch Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_mesa/mesa/work/mesa-19.0.8" && /usr/bin/patch -p1 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/x11/mesa/files/static-strndup.patch'
:info:patch Exit code: 1
:error:patch Failed to patch mesa: command execution failed
:debug:patch Error code: CHILDSTATUS 44780 1
:debug:patch Backtrace: command execution failed
:

this is on 10.6 64bit

Attachments (1)

main.log (12.4 KB) - added by rmottola (Riccardo) 7 weeks ago.
full build log

Download all attachments as: .zip

Change History (14)

Changed 7 weeks ago by rmottola (Riccardo)

Attachment: main.log added

full build log

comment:1 Changed 7 weeks ago by jmroot (Joshua Root)

Summary: cannot build mesa - failed to patchmesa @19.0.8_0+osmesa+python27 patch failure on 10.6

comment:2 Changed 7 weeks ago by kencu (Ken)

I'm working on this one now -- just removing that patch, and it's building away now.

The legacysupport PG should allow more of mesa to "just work" without the patches -- but the d*mn libc++ / thread_local issue on 10.6.8 is a problem for the buildbot. I will go ahead soon and just override that I think.

comment:3 Changed 7 weeks ago by rlhamil

Cc: rlhamil added

comment:4 Changed 6 weeks ago by ballapete (Peter Dyballa)

Cc: ballapete added

comment:5 Changed 6 weeks ago by ballapete (Peter Dyballa)

On PPC Leopard, Mac OS X 10.5.8 I get a different patch failure:

MACOSX_DEPLOYMENT_TARGET='10.5'
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_x11_mesa/mesa/work/mesa-19.0.8" && /usr/bin/patch -p1 < '/opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/x11/mesa/files/no-missing-prototypes-error.patch'
DEBUG: system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_x11_mesa/mesa/work/mesa-19.0.8" && /usr/bin/patch -p1 < '/opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/x11/mesa/files/no-missing-prototypes-error.patch'
patching file configure.ac
Hunk #1 FAILED at 292.
1 out of 1 hunk FAILED -- saving rejects to file configure.ac.rej
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_x11_mesa/mesa/work/mesa-19.0.8" && /usr/bin/patch -p1 < '/opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/x11/mesa/files/no-missing-prototypes-error.patch'
Exit code: 1

comment:6 Changed 6 weeks ago by kencu (Ken)

I fixed that patch failure trivially easily of course, but after that mesa doesn't build at present on 10.6 for other reasons (the OpenGL headers are different, and it won't compile).

So I just pegged it at 17.x on all the older systems <https://github.com/kencu/LeopardPorts/commit/3af9cdfb95e62503764f7bd99cdbb07a670db65e> while I decide when & how to fix that later.

comment:7 Changed 6 weeks ago by ballapete (Peter Dyballa)

The file src/mesa/drivers/dri/common/xmlconfig.c has gone, so static-strndup.patch could become smaller – but there are a few files that use strndup():

mesa-19.0.8/src/amd/common/ac_binary.c:			binary->disasm_string = strndup(section_data->d_buf,
mesa-19.0.8/src/compiler/spirv/spirv_to_nir.c:   char *dup = ralloc_strndup(b, (char *)words, word_count * sizeof(*words));
mesa-19.0.8/src/egl/drivers/dri2/platform_x11.c:         strndup(driver_name,
mesa-19.0.8/src/egl/drivers/dri2/platform_x11.c:      strndup(device_name,
mesa-19.0.8/src/gallium/drivers/r600/evergreen_compute.c:			binary->disasm_string = strndup(section_data->d_buf,
mesa-19.0.8/src/gallium/drivers/radeonsi/si_debug.c:		p = copy = strndup(p, semicolon - p);
mesa-19.0.8/src/loader/loader.c:   driver = strndup(version->name, version->name_len);
mesa-19.0.8/src/util/ralloc.c:ralloc_strndup(const void *ctx, const char *str, size_t max)
mesa-19.0.8/src/util/ralloc.h: * Like \c strndup, at most \p n characters are copied.  If \p str is longer
mesa-19.0.8/src/util/ralloc.h:char *ralloc_strndup(const void *ctx, const char *str, size_t n) MALLOCLIKE;
mesa-19.0.8/src/util/strndup.h:strndup(const char *str, size_t max)
mesa-19.0.8/src/util/xmlconfig.c:        v->_string = strndup(string, STRING_CONF_MAXLEN);

The last one could be the new version of src/mesa/drivers/dri/common/xmlconfig.c… (Anyway, I am going to wait for a solution.)

comment:8 Changed 6 weeks ago by macportsraf

Cc: macportsraf added

comment:9 in reply to:  5 Changed 6 weeks ago by ballapete (Peter Dyballa)

Replying to ballapete:

On PPC Leopard, Mac OS X 10.5.8 I get a different patch failure:

On PPC Tiger, Mac OS X 10.4.11, I see the same failure.

comment:10 Changed 6 weeks ago by ballapete (Peter Dyballa)

There seems to be another bug, because port echo dependentof:mesa reports:

cairo                           
freeglut                        
gtk3                            
libGLU     

but port -vd upgrade libspectre leads to the build failure of mesa.

comment:11 in reply to:  10 Changed 6 weeks ago by ballapete (Peter Dyballa)

Replying to ballapete:

There is no bug, there is another dependency:

Library Dependencies: ghostscript, cairo

comment:12 Changed 6 weeks ago by kencu (Ken)

There has been a longstanding (since 2005) difference of opinion on one of mesa's variable definitions.

Various workarounds were put in place to handle the Apple differences.

For some reason that no longer works, at least on 10.6, and I just haven't dug in on why yet.

It has nothing to do with legacysupport, other ports, etc etc as far as I can see.

I'll get to it eventually. For now I pegged mesa as there are other pressing issues of higher priority, eg. a PR queue so long nobody could see the end of it, with dozens and dozens of DEAD PRs sitting around collection worms that needed to be cleared out.

comment:13 Changed 5 weeks ago by kencu (Ken)

Resolution: fixed
Status: assignedclosed

closed by [3ebe074a74ffe4e8880c733b5d4ef14b2a1c2ff6/macports-ports]

although this doesn't fix the build of mesa on < 10.7 yet...

Note: See TracTickets for help on using tickets.