gavl fails to build with llvm-gcc-4.2

[macports@…]

The build of the port gavl bails with an error. The end of the log is copied below.

:info:build libtool: compile:  /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../include/gavl -I../include -I../include/gavl -I../include -I/usr/local/include -D__GAVL__ -pipe -O2 -arch x86_64 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -MT frametable.lo -MD -MP -MF .deps/frametable.Tpo -c frametable.c  -fno-common -DPIC -o .libs/frametable.o
:info:build libtool: compile:  /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../include/gavl -I../include -I../include/gavl -I../include -I/usr/local/include -D__GAVL__ -pipe -O2 -arch x86_64 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -MT interleave.lo -MD -MP -MF .deps/interleave.Tpo -c interleave.c  -fno-common -DPIC -o .libs/interleave.o
:info:build mv -f .deps/interleave.Tpo .deps/interleave.Plo
:info:build /bin/sh ../libtool --tag=CC   --mode=compile /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../include/gavl -I../include -I../include/gavl -I../include  -I/usr/local/include -D__GAVL__ -pipe -O2 -arch x86_64  -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -MT memcpy.lo -MD -MP -MF .deps/memcpy.Tpo -c -o memcpy.lo memcpy.c
:info:build libtool: compile:  /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../include/gavl -I../include -I../include/gavl -I../include -I/usr/local/include -D__GAVL__ -pipe -O2 -arch x86_64 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -MT memcpy.lo -MD -MP -MF .deps/memcpy.Tpo -c memcpy.c  -fno-common -DPIC -o .libs/memcpy.o
:info:build mv -f .deps/frametable.Tpo .deps/frametable.Plo
:info:build memcpy.c: In function ‘linux_kernel_memcpy_impl’:
:info:build memcpy.c:167: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type!
:info:build /bin/sh ../libtool --tag=CC   --mode=compile /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../include/gavl -I../include -I../include/gavl -I../include  -I/usr/local/include -D__GAVL__ -pipe -O2 -arch x86_64  -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -MT mix.lo -MD -MP -MF .deps/mix.Tpo -c -o mix.lo mix.c
:info:build make[2]: *** [memcpy.lo] Error 1
:info:build make[2]: *** Waiting for unfinished jobs....
:info:build libtool: compile:  /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I../include/gavl -I../include -I../include/gavl -I../include -I/usr/local/include -D__GAVL__ -pipe -O2 -arch x86_64 -O3 -funroll-all-loops -fomit-frame-pointer -ffast-math -Wall -Wmissing-declarations -Wdeclaration-after-statement -mfpmath=387 -fvisibility=hidden -MT mix.lo -MD -MP -MF .deps/mix.Tpo -c mix.c  -fno-common -DPIC -o .libs/mix.o
:info:build mv -f .deps/mix.Tpo .deps/mix.Plo
:info:build make[2]: Leaving directory `/usr/local/var/macports/build/_usr_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_gavl/gavl/work/gavl-1.2.0/gavl'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/usr/local/var/macports/build/_usr_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_gavl/gavl/work/gavl-1.2.0/gavl'
:info:build make: *** [all-recursive] Error 1
:info:build make: Leaving directory `/usr/local/var/macports/build/_usr_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_gavl/gavl/work/gavl-1.2.0'
:info:build shell command " cd "/usr/local/var/macports/build/_usr_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_gavl/gavl/work/gavl-1.2.0" && /usr/bin/make -j2 -w all " returned error 2
:error:build Target org.macports.build returned: shell command failed (see log for details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: the following items did not execute (for gavl): org.macports.activate org.macports.build org.macports.destroot org.macports.install
:error:build Failed to install gavl
:notice:build Log for gavl is at: /usr/local/var/macports/logs/_usr_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_gavl/gavl/main.log

Seems odd to me that it brings its own memcpy, more odd that its blowing up on some inline assembler. However, there is a hint higher up in the log.

:info:configure checking for libpng... yes
:info:configure /var/tmp//ccm1Wz71.s:18:suffix or operands invalid for `push'
:info:configure /var/tmp//ccm1Wz71.s:18:suffix or operands invalid for `pop'
:info:configure /var/tmp//ccm1Wz71.s:71:suffix or operands invalid for `push'
:info:configure /var/tmp//ccm1Wz71.s:71:suffix or operands invalid for `pop'
:info:configure /var/tmp//ccm1Wz71.s:80:suffix or operands invalid for `push'
:info:configure /var/tmp//ccm1Wz71.s:80:suffix or operands invalid for `pop'
:info:configure /var/tmp//ccm1Wz71.s:93:suffix or operands invalid for `push'
:info:configure /var/tmp//ccm1Wz71.s:93:suffix or operands invalid for `pop'
:info:configure /var/tmp//ccm1Wz71.s:143:suffix or operands invalid for `push'
:info:configure /var/tmp//ccm1Wz71.s:143:suffix or operands invalid for `pop'
:info:configure ./cpuinfo.sh: line 78: ./cpuinfo: No such file or directory
:info:configure ./cpuinfo.sh: line 79: ./cpuinfo: No such file or directory
:info:configure ./cpuinfo.sh: line 80: ./cpuinfo: No such file or directory
:info:configure ./cpuinfo.sh: line 81: ./cpuinfo: No such file or directory
:info:configure ./cpuinfo.sh: line 82: ./cpuinfo: No such file or directory
:info:configure ./cpuinfo.sh: line 83: ./cpuinfo: No such file or directory
:info:configure ./cpuinfo.sh: line 86: ./cpuinfo: No such file or directory
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports Your flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports does flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports not flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports even flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports support flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports "i386" flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports for flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports '-march' flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports and flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports -mtune. flags... no
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports -O3 flags... yes
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports -funroll-all-loops flags... yes
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports -fomit-frame-pointer flags... yes
:info:configure checking if /Developer/usr/bin/llvm-gcc-4.2 supports -ffast-math flags... yes
:info:configure checking Architecture... IA32

IA32, really? Interesting, since the build target arch is x86_64.

[macports@…]

And again, this stupid site strips the newlines from the pasted text while leaving those in the text I typed. How does it even manage suck a cock-up? At least its not as bad a couple weeks ago when it was stripping ALL newlines on submissions I made. Also, the log lines have a sufficiently consistent prefix to be able to quickly unwrap the text in a decent editor.

[jmroot (Joshua Root)]

You should just use an attachment for the log.

[ryandesign (Ryan Carsten Schmidt)]

Please read WikiFormatting for help properly formatting text in Trac.

[macports@…]

Replying to ryandesign@…:

Please read WikiFormatting for help properly formatting text in Trac.

The formatting rules describe a paragraph break and how to add a line return into a single line of text. They do no state the criteria for when existing line returns may be removed. It is not explicitly stated, but I can surmise that block quoting would probably be appropriate for logs excerpts. Unfortunately, I am not able to edit my original text so I can only test that theory on the next ticket. If this is the solution, a hint near the description box (in addition to a less miniscule text entry box) may be appropriate.

Replying to jmr@…:

You should use an attachment for the log.

I was attempting to point out two sections of the log that seemed to be pertinent rather than forcing everyone to wade through the entire thing. I can also attach the whole log if you want to read through it.

[michaelallenwarner@…]

My gavl log file documenting failure to build gavl on my machine using OS X Lion

[michaelallenwarner@…]

I am also having trouble building gavl. I'm using Lion (10.7), and I've attached the log file. Any assistance would be greatly appreciated. Thanks!

[michaelallenwarner@…]

P.S. I'm not sure if this makes any difference, but since the whole 32-bit vs. 64-bit thing seems to have come up in the OP by jmr@…, I thought I'd mention that my Mac's hardware (MacBook 4,1 from early 2008) is too old to run the operating system in 64 bits. So my OS Lion runs in 32 bits (though apps can run in 64 bits).

Replying to michaelallenwarner@…:

I am also having trouble building gavl. I'm using Lion (10.7), and I've attached the log file. Any assistance would be greatly appreciated. Thanks!

[wsstefan@…]

any progress on this?

been trying to install kdenlive for days and this is a dependency

thanks!

[michaelallenwarner@…]

Replying to wsstefan@…:

any progress on this?

been trying to install kdenlive for days and this is a dependency

thanks!

That is also what I was trying to do when I posted my log file earlier this month (install kdenlive, that is)... gavl is the last piece of the puzzle.

I lack the know-how to find a fix for this myself, but I'm sure that if someone more knowledgeable than I looks at this ticket and tries to come up with a fix, it would be helpful for them to know some details about your system. Are you using the new OS X Lion (10.7) like I am? Could you post your log file like I did?

[rick@…]

Looks like I've run up against the same problem.
I'm attaching two files, the gavl/main.log and my macBook Pro SystemSoftwareOverview.

[rick@…]

Rick Lloyd's gavl/main.log

[rick@…]

Rick Lloyd's SystemSoftwareOverview

[albanx99@…]

Does gavl even have a maintainer? In the macports index it says: "Maintained by: nomaintainer".

If I even had a clue about how MacPorts works behind the scene, I would have tried to nail that bug and commit a patch, but I don't.

For the record, my MacBooks is kept alive with Lion 64-bit, and XCode 4.1.1 backs up my MacPorts installation.

[macports@…]

I finally got around to fiddling with this and my initial instinct was correct, the problem is caused by incorrect architecture detection. If I edit the configure script to force x86_64, then the build completes without error. I'd submit a patch, but it'd be a hack that would then break anyone on plain i386. Someone who knows autotools and is willing to deal with that garbage heap needs to make a proper patch.

In the meantime, here are the steps to build gavl quick and easy. 1) sudo port extract gavl 2) cd /usr/local/var/macports/build/[long dir name depending on how your ports are fetched]gavl/work/gavl-1.2.0 3) sudo vi configure: edit line 3106 to read host_cpu=x86_64 4) sudo port install gavl

Tested on OS X 10.6.8 on Cire2Duo running 64bit kernel and userland (all ports build for x86_64 only) with most current macports.

A little more info for those who might care to hack up the configure script. Line 3106 sets the host_cpu variable to the results of a routine called from config.sub. That should be the cpu id of the buildhost, which should just be result of uname -m, except this is autotools trash so a few thousands lines of shell script are executed to cone up with the same answer (or in this case, NOT the same answer). That host_cpu variable is used on line 11555 to set the architecture, where i[3-7]86 sets ARCH_X86=true, and x86_64 also sets ARCH_X86_64=true. That latter variable makes a significant difference, setting it cleans up some errors that were coming from configure right around where it shows the detected architecture. As the host_cpu variable is used in numerous other places, I decided to override it as its the base of the problem, rather than just set the flag here and risk other problems. With the override on line 3106, I get detected architecture x86_64 (correct) instead of previous IA32 (incorrect) and the build and cleanly finish.

[macports@…]

Replying to macports@…:

Great... forgot to escape basic text so the wiki ate some line returns and turned some text into a nonsense link. i'd fix it, but this ghetto shit has no edit function, so fuckit

[macports@…]

Replying to michaelallenwarner@…:

P.S. I'm not sure if this makes any difference, but since the whole 32-bit vs. 64-bit thing seems to have come up in the OP by jmr@…, I thought I'd mention that my Mac's hardware (MacBook 4,1 from early 2008) is too old to run the operating system in 64 bits. So my OS Lion runs in 32 bits (though apps can run in 64 bits).

The ONLY Intel Mac that can't run 64bit code is the original Core Duo MacBook Pro. All subsequent machines are at least Core2 which can run 64bit code. The CPU should be the only thing that determines what code you can run, and sure enough you can run plenty of 64bit apps. However, Apple installed a 32bit build of EFI on their Macs for several years and only switched to 64bit EFI relatively recently. That 64bit EFI is needed to run the kernel in 64bit mode as the bootloader lacks the ability to switch modes and launch a 64bit kernel from a 32bit environment. A little shim can be used during the boot to fix this. Before going to that trouble though, its worth testing what happens if you set the flag since even some machines with a 64bit EFI (like my 2008 MacBook Pro) still boot the kernel in 32bit mode by default. All that aside, it really doesn't matter if kernel is in 32 or 64bit mode to anything but a kext (drivers). All apps can execute in either regardless of which mode the kernel is in, so long as all dependent libraries are in the correct bitness for the app. AFAIK, macports will build x86_64 apps and libs as long as the CPU is capable, unless your macports.conf is changed or you set +universal. So, to make long story short, your machine isn't too old to run 64bit and most likely your entire macports collection is being built for 64bit, including gavl.

[michaelallenwarner@…]

Replying to macports@…:

Replying to michaelallenwarner@…:

P.S. I'm not sure if this makes any difference, but since the whole 32-bit vs. 64-bit thing seems to have come up in the OP by jmr@…, I thought I'd mention that my Mac's hardware (MacBook 4,1 from early 2008) is too old to run the operating system in 64 bits. So my OS Lion runs in 32 bits (though apps can run in 64 bits).

The ONLY Intel Mac that can't run 64bit code is the original Core Duo MacBook Pro. All subsequent machines are at least Core2 which can run 64bit code. The CPU should be the only thing that determines what code you can run, and sure enough you can run plenty of 64bit apps. However, Apple installed a 32bit build of EFI on their Macs for several years and only switched to 64bit EFI relatively recently. That 64bit EFI is needed to run the kernel in 64bit mode as the bootloader lacks the ability to switch modes and launch a 64bit kernel from a 32bit environment. A little shim can be used during the boot to fix this. Before going to that trouble though, its worth testing what happens if you set the flag since even some machines with a 64bit EFI (like my 2008 MacBook Pro) still boot the kernel in 32bit mode by default. All that aside, it really doesn't matter if kernel is in 32 or 64bit mode to anything but a kext (drivers). All apps can execute in either regardless of which mode the kernel is in, so long as all dependent libraries are in the correct bitness for the app. AFAIK, macports will build x86_64 apps and libs as long as the CPU is capable, unless your macports.conf is changed or you set +universal. So, to make long story short, your machine isn't too old to run 64bit and most likely your entire macports collection is being built for 64bit, including gavl.

Thanks for clarifying this (and of course when I said in my previous post that the OP was by jmr, I was mistaken and meant you). I will try to build gavl very soon using the directions you have provided. Will report back soon.

Thanks again.

[michaelallenwarner@…]

Believe it or not, I must have been right about my Macbook 4,1 and the whole 32-bit vs. 64-bit thing. When I tried installing gavl using your method (typing "x86_64" into line 3106), I encountered the same problems. As soon as I typed "x86_32" into the same line, the problem was fixed and gavl seems to have installed!

Many thanks for pointing me in the direction.

[danielluke (Daniel J. Luke)]

Macbook4,1 has a core2duo (and so can run 64bit binaries). In fact, if you're running 10.7 (Lion) you know you can run 64bit binaries. There's probably some other reason why your 'fix' worked.

[michaelallenwarner@…]

My machine *is* too old to run the 64-bit kernel. On paper everything is fine: I have a Core 2 Duo processor, and when I check my EFI in Terminal with "ioreg -l -p IODeviceTree | grep firmware-abi", it returns EFI64 (not EFI32). Nonetheless, my model is incapable of running the 64-bit kernel (again, 64-bit apps run just fine in the 32-bit environment). As I understand it, it's an artificial limitation that Apple placed on the MacBook 4,1. It's quite stupid that my 2008 model has this artificial limitation, while the iMac 7,1 from 2007 apparently boots to the 64-bit kernel by default in Lion. That's the way it is.

Is it possible that the "host_cpu" in the gavl config file needs to match the kernel's architecture? If not, I'm at a loss as to why my "fix" worked.

[macports@…]

Replying to michaelallenwarner@…:

My machine *is* too old to run the 64-bit kernel. On paper everything is fine: I have a Core 2 Duo processor, and when I check my EFI in Terminal with "ioreg -l -p IODeviceTree | grep firmware-abi", it returns EFI64 (not EFI32). Nonetheless, my model is incapable of running the 64-bit kernel (again, 64-bit apps run just fine in the 32-bit environment). As I understand it, it's an artificial limitation that Apple placed on the MacBook 4,1. It's quite stupid that my 2008 model has this artificial limitation, while the iMac 7,1 from 2007 apparently boots to the 64-bit kernel by default in Lion. That's the way it is.

Is it possible that the "host_cpu" in the gavl config file needs to match the kernel's architecture? If not, I'm at a loss as to why my "fix" worked.

See ​http://www.ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html

That works for me to run my MBP5,2 with 64bit kernel. Should work for your 4,1 as well.

[michaelallenwarner@…]

Replying to macports@…:

Replying to michaelallenwarner@…:

My machine *is* too old to run the 64-bit kernel. On paper everything is fine: I have a Core 2 Duo processor, and when I check my EFI in Terminal with "ioreg -l -p IODeviceTree | grep firmware-abi", it returns EFI64 (not EFI32). Nonetheless, my model is incapable of running the 64-bit kernel (again, 64-bit apps run just fine in the 32-bit environment). As I understand it, it's an artificial limitation that Apple placed on the MacBook 4,1. It's quite stupid that my 2008 model has this artificial limitation, while the iMac 7,1 from 2007 apparently boots to the 64-bit kernel by default in Lion. That's the way it is.

Is it possible that the "host_cpu" in the gavl config file needs to match the kernel's architecture? If not, I'm at a loss as to why my "fix" worked.

See ​http://www.ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html

That works for me to run my MBP5,2 with 64bit kernel. Should work for your 4,1 as well.

Nope -- I'm on a MacBook 4,1 (not a MBP 4,1). The MBP 4,1 and MacPro 4,1 are capable of running 64-bit kernel, as the chart on that site you linked to shows, but not the MacBook 4,1. Many MacBooks like mine (and perhaps some Mac Mini models?)are artificially prohibited by Apple from running 64-bit kernel, even though the hardware is otherwise fully capable.

[jmroot (Joshua Root)]

r87189