port orc fail to build for i386 with -O2

[develop@…]

No error raised, just warnings. See the build log

[develop@…]

build log for orc-0.4.11

[rb@…]

Cc Me!

[rb@…]

Orc build log

[rb@…]

I also have a build failure for orc, but it's something more subtle and worrying:

/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I../..   -I/opt/local/include -Wall -I../.. -O2 -arch i386 -MT testorc.o -MD -MP -MF .deps/testorc.Tpo -c -o testorc.o testorc.c
/var/tmp//ccNcBJ0J.s:11487:non-relocatable subtraction expression, "LC0" minus "L00000000006$pb"

See attached full log.

[eborisch (Eric A. Borisch)]

FWIW, x86_64 builds fine for me; i386 fails with the same (non-relocatable subtraction) error listed above (10.6.4, XCode 3.2.4)

[manphiz@…]

Cc Me!

[mherrb@…]

Cc Me!

[jingbo1983@…]

Replying to mherrb@…:

Cc Me!

[rmstonecipher@…]

r72564 should keep people from building orc +universal.
I don't know how to explicitly forbid building for i386 architecture, so if any of y'all do know how to do so I would appreciate your help.

Ryan

[neilj@…]

Error is still occurring for me on both a clean install and an upgrade. The error message is the same as reported by rb, so I've not attached a new main.log file.

Please note that the two systems I have (MacBook and MacMini) are both first generation Intel Macs so they have the 32bit Intel Core Duo processors and hence I have to build for i386 architecture, x86_64 is not an option.

Disabling i386, aside from not working in this instance as the build is still allowed to be attempted, is not really a solution as it prevents people like me from using other MacPorts that depend on Orc. In my instance this is schroedinger, which is in turn used by ffmpeg and this in turn by the Mediatomb UPNP server.

[tobias@…]

Cc Me!

[arc@…]

Cc Me!

[vulcan_@…]

i am seeing that same issue .. the "non-relocatable subtraction expression, "LC0" minus "L00000000006$pb" thing on an older macBook, so 32 bit Duo Core .. in an up to date Snow Leopard + XCode installation. I just trashed ffmpeg rather than have the build problem .. i don't use it anyway .. pity that schroedinger is built on an oddball basis like ORC.

[theorikbn@…]

Maybe a solution might be to make ffmpeg dependencies more flexible (±schroedinger) instead of enabling everything or nothing, as it's done at the moment?

(Should this be posted in an ffmpeg ticket?)

[develop@…]

orc is also a dependency for gstreamer (gst-plugins-base). We cannot lose gstreamer on i386 because of orc. Maybe as for ffmpeg we could build gst-plugins-base without orc?

[vulcan_@…]

Replying to develop@…:

orc is also a dependency for gstreamer (gst-plugins-base). We cannot lose gstreamer on i386 because of orc. Maybe as for ffmpeg we could build gst-plugins-base without orc?

further update from the trenches .. someone went made GIMP dependent on Schroedinger, which tries to build ORC .. boom !!

so the best OS image manip tool is now not installable via MacPorts

[chandramohan.rangaswamy@…]

Replying to vulcan_@…:

Replying to develop@…:

orc is also a dependency for gstreamer (gst-plugins-base). We cannot lose gstreamer on i386 because of orc. Maybe as for ffmpeg we could build gst-plugins-base without orc?

further update from the trenches .. someone went made GIMP dependent on Schroedinger, which tries to build ORC .. boom !!

so the best OS image manip tool is now not installable via MacPorts

The issue seems to be due to the optimization flag -O2. Disabling the optimization makes the issue go away.

This is what I did:

cd <workdir>/orc-0.4.11/testsuite/orcc

modify Makefile to remove -O2 flag from the CFLAGS and CCASFLAGS

cd ../..

make

I am not sure if this is the right thing to do. I was just trying to get the debugging symbols to investigate further, but then saw that the compilation goes through when -O2 is disabled. Did not investigate any further than that. I am guessing that this is fine as this is happening in testsuite alone? Schroedinger/ffmpeg compiled fine afterwards.

[chandramohan.rangaswamy@…]

Compilation error isolated

[chandramohan.rangaswamy@…]

Ok, did some more work and isolated the error (at least where my compiler barfs). The error happens in function '_backup_convert_fc32_to_int32', between the blocks marked in the attached orc_test.c file. Looks like some optimization problem in the way union members are accessed. Unfortunately that is all I could figure out.

[chandramohan.rangaswamy@…]

Cc Me!

[loves007@…]

Cc Me!

[raphael-st (Raphael Straub)]

Cc Me!

[vulcan_@…]

Replying to chandramohan.rangaswamy@…:

Ok, did some more work and isolated the error (at least where my compiler barfs). The error happens in function '_backup_convert_fc32_to_int32', between the blocks marked in the attached orc_test.c file.

i have done some more digging too .. or at least i got Google to do it for me. same error messages appeared in 2003 for a ​guy working on Ada on Mac OS

and in 2003 they showed up for a guy ​working on a related problem on a Power PC package ..

and in 2007 there was a problem with the ​Liquid Rescale GIMP plugin

hope this helps

so .. it can happen in

[vulcan_@…]

and possibly this issue in the GCC 3.3.2 is related (also in 2003) ​http://gcc.gnu.org/ml/gcc-bugs/2003-11/msg01552.html

there were patches supplied that fixed the problem so there may be a clue in there? i have not looked further than the bug report thread due to time constraints .. i have installed the binary of the latest GIMP so i am good to go.

[vulcan_@…]

hi again .. sorry to be treating this like a blog but with the -O2 removed per the hint above i was able to get ORC installed, and then GIMP followed, and it brought ffmpeg with it. so the workaround works.

good luck with the real fix.

[endingelysium@…]

Deleting the -O2 tag worked for me as well as a workaround using Snow Leopard 10.6.4 (32-bit only).

OpenCV was able to build without issue.

[rmstonecipher@…]

This ​article on gcc optimization includes an image of a table showing the individual optimizations included in -O1, -O2, -Os, and -O3.
Neither -O2 or -Os worked for a build architecture of i386 on my Core 2 Duo Macbook; however, -O1 worked.
It follows that one or more of the 17 optimizations included in -Os but not -O1 keeps us from using -Os.
To fix the Portfile I added:

configure.optflags-append -Xarch_i386 -O1

If any of y'all can determine which optimizations from -Os/-O2 cause the error in this ticket, we could likely disable just those optimizations rather than dropping all the way to -O1.
Fixed in r73050.

[neverlunch@…]

Portfile's diff for universal

[neverlunch@…]

orc/orcpowerpc.c's diff for universal.

[neverlunch@…]

Universal (i386, x86_64, ppc) succeeded, BUT :

libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include -Wall -I.. -DORC_ENABLE_UNSTABLE_API -pipe -O2 
-Xarch_i386 -O1 -Xarch_x86_64 -O3 -arch ppc -c orcpowerpc.c  -fno-common -DPIC -o .libs/liborc_0.4_la-orcpowerpc.o
{standard input}:176:Parameter error: r0 not allowed for parameter 1 (code as 0 not r0)

This failure led me to search. After some attempts inspired from ​http://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints, I got a successfully compiled universal orc. So, this

__asm__ __volatile__ ("dcbst %0,%1" :: "r" (ptr), "r" (i));

became

__asm__ __volatile__ ("dcbst %0,%1" :: "b" (ptr), "r" (i));

I'm waiting for any PowerPC expert to shout on me. ;}

I also looked into the weird "i386 -O2" error... Wouldn't it be a bug in Apple's gcc ? Does this make sense to someone ?

leal	LC0-"L00000000006$pb"(%ebx), %eax

[neverlunch@…]

backup_convert_fc32_to_int32 x86 asm (orc/orcpowerpc.c)

[jmroot (Joshua Root)]

This ticket was never about ppc. Open a new one for that, and better yet send the patch upstream.