Opened 12 years ago
Closed 2 years ago
#36041 closed defect (fixed)
gimp2: build fails on 10.5.8 PPC
Reported by: | mklein-de (Michael Klein) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | powerpc | Cc: | potmj (Michael Pot), prynhart@…, ryandesign (Ryan Carsten Schmidt), kencu (Ken) |
Port: | gimp2 |
Description
find build log attached
Attachments (5)
Change History (25)
Changed 12 years ago by mklein-de (Michael Klein)
comment:1 follow-up: 2 Changed 12 years ago by mklein-de (Michael Klein)
There was a similar altivec issue for gegl (#35148) recently.
The failing command is:
fjelljo:~/var/macports/sources/svn.macports.org/graphics/gimp2/work/gimp-2.8.2/app/core $ /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../app -I../../app -I/opt/local/include/cairo -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng15 -D_REENTRANT -I/opt/local/include/gegl-0.2 -I/opt/local/include/babl-0.1 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -D_REENTRANT -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng15 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include -DGIMP_APP_VERSION=\"2.8\" -DG_LOG_DOMAIN=\"Gimp-Core\" -I/opt/local/include -DGIMP_DISABLE_DEPRECATED -DBABL_DISABLE_DEPRECATED -DGSEAL_ENABLE -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -pipe -O2 -arch ppc -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -Wmissing-format-attribute -Wformat-security -fno-common -MT gimpdrawable.o -MD -MP -MF .deps/gimpdrawable.Tpo -c -o gimpdrawable.o gimpdrawable.c
Somewhat surprisingly, the code compiles if I add -faltivec
or -fno-altivec
comment:2 Changed 12 years ago by mklein-de (Michael Klein)
FWIW, the generated app/core/Makefile contains the following unused variable:
ALTIVEC_EXTRA_CFLAGS = -faltivec
comment:3 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | devans@… removed |
---|---|
Keywords: | powerpc added |
Owner: | changed from macports-tickets@… to devans@… |
comment:4 Changed 12 years ago by dbevans (David B. Evans)
Status: | new → assigned |
---|
comment:7 follow-up: 8 Changed 12 years ago by prynhart@…
I have hit this issue on 10.5.8 PPC. Cruically, the "-faltivec" flag seems to work due to the following: :info:build /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/altivec.h:44:2: warning: #warning Ignoring <altivec.h> because "-faltivec" specified
i.e. the compiler doesn't hit the bit of code that it's unhappy with.
I have tried using an alternative compiler (port install gimp configure.compiler=apple-gcc-4.2) but this also hits the same problem.
You might also need to build with +quartz +no_x11 -x11 to hit this issue. (Can the OP confirm whether their variant.conf file has these options, or whether they're manually specifying quartz.)
Please let me know if I can help more. Would be great to get this fixed (and allow some PPC systems to run the latest and greatest Gimp :-) )
comment:8 follow-up: 9 Changed 12 years ago by mklein-de (Michael Klein)
Replying to prynhart@…:
I have hit this issue on 10.5.8 PPC. Cruically, the "-faltivec" flag seems to work due to the following: :info:build /usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/altivec.h:44:2: warning: #warning Ignoring <altivec.h> because "-faltivec" specified
i.e. the compiler doesn't hit the bit of code that it's unhappy with.
I think the warning can be safely ignored. It seems the preferred way to enable Altivec is to compile with "-maltivec" and include altivec.h, but compiling with "-faltivec" instead should do more or less the same.
I compiled both gegl and gimp with -faltivec. I have no idea whether they make use of Altivec intrinsics, but it seems everything seems to work ok.
You might also need to build with +quartz +no_x11 -x11 to hit this issue. (Can the OP confirm whether their variant.conf file has these options, or whether they're manually specifying quartz.)
no, none of these variants is used here
Changed 12 years ago by mklein-de (Michael Klein)
Attachment: | gimp2-Portfile-altivec.patch added |
---|
Patch to compile with -faltivec on PowerPC
comment:9 Changed 12 years ago by potmj (Michael Pot)
Replying to michael.klein@…:
Replying to prynhart@…:
Hi Folks,
I too am hitting this problem, building on 10.5.8 Intel universal gcc 4.0.1 (Apple Inc. build 5493)
Just trying to get up to speed on it, have tried the patch to no effect. It looks to me that the complaint is over the declaration of "pixel", which I guess is the AltiVec pixel.
Anyway, the following difference stands out earlier in my .log file during configure, however there is the same errors at the end:-
My main.log reports the following with or without the patch
:info:configure checking for socket in -lsocket... no :info:configure checking whether /usr/bin/gcc-4.0 understands -mmmx... no :info:configure checking whether we can compile MMX code... no :info:configure configure: WARNING: The assembler does not support the MMX command set. :info:configure checking for shm_open... yes
Whereas the attached main.log reports
:info:configure checking for socket in -lsocket... no :info:configure checking whether /usr/bin/gcc-4.0 understands -faltivec... yes :info:configure checking whether we can compile AltiVec code... yes :info:configure checking for shm_open... yes
Not sure where I have gone wrong, perhaps something else needs setting, or configure is not doing the combination of PPC & i386 correctly.
many thanks michael
OK, [variant_isset universal] did not work for me on 10.5.8 Intel universal gcc 4.0.1 (build 5493)
My solution was to use the -Xarch option, which I think might be a better solution for the range of hardwares now needed to be supported.
I am not to familiar with other/newer CPU & OS requirements, so I am not too sure what conditions need to be put around the flag additions in the patch to make it work in all cases, but as it moves the decision to the compiler where it has already been coded, I guess it is better than repeating all that work in the Portfile.
Hopes this helps others.
Michael Pot
Changed 12 years ago by potmj (Michael Pot)
Attachment: | main.2.log added |
---|
Changed 12 years ago by potmj (Michael Pot)
Attachment: | Portfile-ppc-universal-altivec.patch added |
---|
-Xarch control for 10.5.8 Intel universal builds to support AltiVec
comment:12 Changed 12 years ago by prynhart@…
Looks good. The patch seems to work :) (Successfully compiled gimp2 on an iBook G4.)
Changed 11 years ago by newchief@…
Attachment: | macports-gimp2.8.tar.bz2 added |
---|
My changes to ports required to build gimp 2.8
comment:13 follow-up: 14 Changed 11 years ago by newchief@…
I attached my changes to ports that I made to complete build of gimp 2.8.10 (quartz, no X!) on my old PowerMac G5. Tested today with recent sync. These are: boost gcr gegl gimp2 glib2
What's changed in gimp? Instead of adding -faltivec, I rearranged inclusion of GTK/GDK files or renamed local variables (mostly from pixel to just p). This seem to be more reasonable than applying one compilation policy over all compiled package. The most crucial change is in glib2. When I built gimp, I couldn't start it. It crashed right after splash screen with following backtrace:
(gimp-2.8:7170): GLib-GObject-WARNING : gvalue.c:183: cannot initialize GValue with type 'gchararray', the value has already been initialized as '(null)'
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x44424414 0x01264370 in g_type_check_value () (gdb) bt #0 0x01264370 in g_type_check_value () #1 0x0126bce8 in g_value_transform () #2 0x0124fce4 in g_object_new_internal () #3 0x01250214 in g_object_new_valist () #4 0x01250578 in g_object_new () #5 0x0016547c in gimp_prop_spin_scale_new () #6 0x00096f70 in gimp_selection_options_gui () #7 0x0008b67c in gimp_rectangle_select_options_gui () #8 0x00055604 in gimp_tools_restore () #9 0x000128d0 in gui_restore_callback () #10 0x01246368 in g_closure_invoke () #11 0x0125cff8 in signal_emit_unlocked_R () #12 0x0125e85c in g_signal_emit_valist () #13 0x0125ebe4 in g_signal_emit () #14 0x0000e024 in app_run () #15 0x00010884 in main () (gdb)
This '(null)' in warning seemed suspicious to me so I added another 'if' that checks for that case in glib's g_value_init() function. Seems like it solves the problem.
Other packages like gimp, gutenprint, xsane, ufraw, gipm-app and so on did not require any further changes.
Although PowerMac G5 is ppc64, I've built everything ppc 32-bit. gtk+ cannot be built for ppc64 anyway.
Installed variants of crucial ports:
| atk @2.10.0_0 (active) platform='darwin 9' archs='ppc' | babl @0.1.11_20131014 (active) platform='darwin 9' archs='ppc' | boost @1.55.0_1+no_single+no_static+python27 (active) platform='darwin 9' archs='ppc' | cairo @1.12.16_2+quartz-universal-x11 (active) platform='darwin 9' archs='ppc' | fontconfig @2.11.0_2-universal (active) platform='darwin 9' archs='ppc' | freetype @2.5.2_1-universal (active) platform='darwin 9' archs='ppc' | gcr @3.10.1_1 (active) platform='darwin 9' archs='ppc' | gegl @0.2.0_12+graphviz+python27+quartz-html_doc-universal-workshop-x11 (active) platform='darwin 9' archs='ppc' | gimp @2.8.10_0 (active) platform='darwin 9' archs='noarch' | gimp-app @2.8.2_2 (active) platform='darwin 9' archs='ppc' | gimp2 @2.8.10_5+python27+quartz-gvfs-help_browser-remote-universal (active) platform='darwin 9' archs='ppc' | glib2 @2.38.2_0 (active) platform='darwin 9' archs='ppc' | gnome-keyring @3.10.1_1 (active) platform='darwin 9' archs='ppc' | gtk2 @2.24.22_1+no_x11+quartz-x11 (active) platform='darwin 9' archs='ppc' | gutenprint @5.2.9_2 (active) platform='darwin 9' archs='ppc' | harfbuzz @0.9.25_0-universal (active) platform='darwin 9' archs='ppc' | libpixman @0.32.4_0-universal (active) platform='darwin 9' archs='ppc' | pango @1.36.1_1+quartz-x11 (active) platform='darwin 9' archs='ppc' | ufraw @0.19.2_3 (active) platform='darwin 9' archs='ppc' | xsane @0.998_3 (active) platform='darwin 9' archs='ppc'
comment:14 Changed 11 years ago by mklein-de (Michael Klein)
Replying to newchief@…:
The most crucial change is in glib2. When I built gimp, I couldn't start it. It crashed right after splash screen with following backtrace:
(gimp-2.8:7170): GLib-GObject-WARNING **: gvalue.c:183: cannot initialize GValue with type 'gchararray', the value has already been initialized as '(null)'Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x44424414 0x01264370 in g_type_check_value ()
I've seen this a while ago also with gnumeric. Seems to be caused by a bug in the gcc-4.2 shipped with Xcode. Rebuilding glib2 with apple-gcc42 did the trick for me. Since then I'm using apple-gcc42 as default compiler (port select gcc apple-gcc42)
comment:15 follow-up: 19 Changed 7 years ago by kencu (Ken)
I have this working reasonably well now. As specified, glib2
has to be rebuilt with apple-gcc-4.2
for the program to work correctly. I'll put together a pull request for github for Dave to review.
comment:16 Changed 7 years ago by kencu (Ken)
Cc: | ryandesign added |
---|---|
Version: | 2.1.2 |
Ryan -- glib2
has some kind of bug (at least on PPC) when built with the default gcc-4.2
. I've seen it from time to time, but it shows up when running gimp2
at least. When glib2 is rebuilt with apple-gcc-4.2, gimp2 works correctly.
comment:17 Changed 7 years ago by kencu (Ken)
Cc: | kencu added |
---|
comment:18 Changed 3 years ago by mascguy (Christopher Nielsen)
Owner: | changed from dbevans to mascguy |
---|
comment:19 Changed 2 years ago by mascguy (Christopher Nielsen)
Replying to kencu:
I have this working reasonably well now. As specified,
glib2
has to be rebuilt withapple-gcc-4.2
for the program to work correctly. I'll put together a pull request for github for Dave to review.
I did some quick searching for a related PR, and/or commits, but didn't see anything immediately obvious.
Ken/Ryan, can this be closed?
comment:20 Changed 2 years ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Builds fine on 10.6, and also patched by @kencu to fix PPC:
https://github.com/macports/macports-ports/commit/bff0ad0a7253468e18996d1eca0df2606d4d1ba3
build log