search

digego / extempore

A cyber-physical programming environment
1.41k stars 127 forks source link

libassimp 3.2 fails to build on 64-bit Linux #255

Closed JimKuhn closed 8 years ago

JimKuhn commented 8 years ago

Due to: ef79822a523d02199ac753826dce56a4a157f86d

Reverting to 3.1.1 builds fine. Sorry, I don't have time to dig deeper.

[ 21%] Performing build step for 'assimp'
Scanning dependencies of target zlibstatic
[  1%] Building C object contrib/zlib/CMakeFiles/zlibstatic.dir/adler32.o
...
[  9%] Building C object contrib/zlib/CMakeFiles/zlibstatic.dir/zutil.o
Linking C static library libzlibstatic.a
[  9%] Built target zlibstatic
Scanning dependencies of target assimp
[  9%] Building CXX object code/CMakeFiles/assimp.dir/Assimp.cpp.o
...
[100%] Building CXX object code/CMakeFiles/assimp.dir/__/contrib/openddlparser/code/Value.cpp.o
Linking CXX shared library libassimp.so
/usr/bin/ld: ../contrib/zlib/libzlibstatic.a(compress.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
../contrib/zlib/libzlibstatic.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
code/CMakeFiles/assimp.dir/build.make:4136: recipe for target 'code/libassimp.so.3.2.0' failed
digego commented 8 years ago

No problem building/running assimp 3.2 on Ubuntu 15.10 (64bit) ​

benswift commented 8 years ago

Hi Jim

I've just looked into it, and it looks like they haven't set the POSITION_INDEPENDENT_CODE property on the zlib target (when it's built from source as part of assimp).

Easiest workaround for the moment is probably just to get zlib through your package manager. I'm putting together a bug report from them, but it obviously wouldn't be fixed in 3.2 anyway.

I'll add a note to install.rst as well.

Cheers, Ben

Jim Kuhn notifications@github.com writes:

Due to: ef79822a523d02199ac753826dce56a4a157f86d

Reverting to 3.1.1 builds fine. Sorry, I don't have time to dig deeper.

[ 21%] Performing build step for 'assimp'
Scanning dependencies of target zlibstatic
[  1%] Building C object contrib/zlib/CMakeFiles/zlibstatic.dir/adler32.o
...
[  9%] Building C object contrib/zlib/CMakeFiles/zlibstatic.dir/zutil.o
Linking C static library libzlibstatic.a
[  9%] Built target zlibstatic
Scanning dependencies of target assimp
[  9%] Building CXX object code/CMakeFiles/assimp.dir/Assimp.cpp.o
...
[100%] Building CXX object code/CMakeFiles/assimp.dir/__/contrib/openddlparser/code/Value.cpp.o
Linking CXX shared library libassimp.so
/usr/bin/ld: ../contrib/zlib/libzlibstatic.a(compress.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
../contrib/zlib/libzlibstatic.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
code/CMakeFiles/assimp.dir/build.make:4136: recipe for target 'code/libassimp.so.3.2.0' failed

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/digego/extempore/issues/255

digego commented 8 years ago

Yeah, that makes sense, I already had zlib installed

On Fri, Apr 8, 2016 at 5:51 PM, Ben Swift notifications@github.com wrote:

Hi Jim

I've just looked into it, and it looks like they haven't set the POSITION_INDEPENDENT_CODE property on the zlib target (when it's built from source as part of assimp).

Easiest workaround for the moment is probably just to get zlib through your package manager. I'm putting together a bug report from them, but it obviously wouldn't be fixed in 3.2 anyway.

I'll add a note to install.rst as well.

Cheers, Ben

Jim Kuhn notifications@github.com writes:

Due to: ef79822a523d02199ac753826dce56a4a157f86d

Reverting to 3.1.1 builds fine. Sorry, I don't have time to dig deeper.

[ 21%] Performing build step for 'assimp'
Scanning dependencies of target zlibstatic
[ 1%] Building C object contrib/zlib/CMakeFiles/zlibstatic.dir/adler32.o
...
[ 9%] Building C object contrib/zlib/CMakeFiles/zlibstatic.dir/zutil.o
Linking C static library libzlibstatic.a
[ 9%] Built target zlibstatic
Scanning dependencies of target assimp
[ 9%] Building CXX object code/CMakeFiles/assimp.dir/Assimp.cpp.o
...
[100%] Building CXX object
code/CMakeFiles/assimp.dir/__/contrib/openddlparser/code/Value.cpp.o
Linking CXX shared library libassimp.so
/usr/bin/ld: ../contrib/zlib/libzlibstatic.a(compress.o): relocation
R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared
object; recompile with -fPIC
../contrib/zlib/libzlibstatic.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
code/CMakeFiles/assimp.dir/build.make:4136: recipe for target
'code/libassimp.so.3.2.0' failed

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/digego/extempore/issues/255

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/digego/extempore/issues/255#issuecomment-207284982

JimKuhn commented 8 years ago

Since I always build in a docker container, I try to have the minimum set of dependencies necessary to build. That way I keep all my projects separate and can build on multiple distributions and run on different host distros.

I just added CI (travis) to my fork so I at least get a sanity check of the build (and the status is show the README.md). It don't think it would have caught this problem, however, as I believe the default Travis environment already has an appropriately built zlib installed. I also added a (stripped-down) version of the Dockerfile I use to build my container. The automated build on DockerHub isn't currently working as, for some reason, it takes more than two hours to build on their infrastructure and gets killed.

benswift commented 8 years ago

Ah, cool. Did you base it on https://github.com/extemporelang/extempore-docker ?

My version's far from the be-all-and-end-all of Extempore on docker, and there are certainly lighter-weight ways to to it than using ubuntu as a base.

Is you dockerfile up online somewhere? Also, travis support has been on the wishlist for a while now but I've never got around to it - is it tricky to set up?

Cheers Ben

Jim Kuhn notifications@github.com writes:

Since I always build in a docker container, I try to have the minimum set of dependencies necessary to build. That way I keep all my projects separate and can build on multiple distributions and run on different host distros.

I just added CI (travis) to my fork so I at least get a sanity check of the build (and the status is show the README.md). It don't think it would have caught this problem, however, as I believe the default Travis environment already has an appropriately built zlib installed. I also added a (stripped-down) version of the Dockerfile I use to build my container. The automated build on DockerHub isn't currently working as, for some reason, it takes more than two hours to build on their infrastructure and gets killed.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/digego/extempore/issues/255#issuecomment-208020013

JimKuhn commented 8 years ago

Travis is easy to set up, hard to get the build right... See my .travis.yml file. It just squeaks in under the 50 minute build time limit.

I didn't base my Dockerfile on the one in extemporelang. I always start my Dockerfiles from scratch so I can learn/understand the dependencies. I also use my own preprocessor and 'library' of canned actions to assist in building Dockerfiles.

Since I always build locally (never push to Docker Hub), it isn't that critical that I get the build under the 2 hour limit. If it was, I'd have to split the container in two like yours does.

JimKuhn commented 8 years ago

I've also just added chat via gitter (which I've never used before) to the README.md. It doesn't belong in my fork, but it might be useful upstream (with the right badge details).