Make Failing on Linux Mint

[bvssvni]

mkdir -p lib
rustc --out-dir=lib --link-args="-lglfw3 -lrt -lXrandr -lXi -lGL -lm -ldl -lXrender -ldrm -lXdamage -lX11-xcb -lxcb-glx -lXxf86vm -lXfixes -lXext -lX11 -lpthread -lxcb -lXau -lXdmcp " -O src/lib/lib.rs
error: linking with `cc` failed: exit code: 1
note: cc arguments: '-m64' '-L/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-o' 'lib/libglfw-rs-c68009f4-0.1.so' 'lib/glfw-rs.o' 'lib/glfw-rs.metadata.o' '-Wl,--as-needed' '-Wl,-O1' '-L/home/sven/Desktop/opensource/glfw-rs/.rust' '-L/home/sven/Desktop/opensource/glfw-rs' '-L/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lstd-966edb7e-0.10-pre' '-ldl' '-lm' '-lpthread' '-shared' '-lmorestack' '-Wl,-rpath,$ORIGIN/../../../../../../usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-Wl,-rpath,/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lglfw3' '-lrt' '-lXrandr' '-lXi' '-lGL' '-lm' '-ldl' '-lXrender' '-ldrm' '-lXdamage' '-lX11-xcb' '-lxcb-glx' '-lXxf86vm' '-lXfixes' '-lXext' '-lX11' '-lpthread' '-lxcb' '-lXau' '-lXdmcp'
note: /usr/bin/ld: /usr/local/lib/libglfw3.a(context.c.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libglfw3.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status

By running 'cat /proc/version' I get:
Linux version 3.5.0-17-generic (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012

[brendanzab]

Just curious, can you compile a regular glfw program in C using pkg-config for linking?

[bvssvni]

The examples in the GLFW source works, except for "heightmap" for some reason.

[bvssvni]

According to http://stackoverflow.com/questions/5311515/gcc-fpic-option and looking at the error message it seems that the /usr/local/lib/libglfw3.a file is compiled wrongly somehow. Will try to figure out how to include the -fPIC flag when compiling GLFW.

[bvssvni]

It works! I edited 'CMakeCache.txt' in the GLFW source to:

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=-fPIC

Recompiled and reinstalled, it now links propertly with glfw-rs

[brendanzab]

The examples in the GLFW source works, except for "heightmap" for some reason.

I meant when compiling a free-standing glfw program written in C, using the instructions here: http://www.glfw.org/docs/latest/build.html#build_link_pkgconfig

I want to ascertain whether it's a glfw problem or a glfw-rs problem. You shouldn't have to edit the cmake files.

[aiwenar]

@bvssvni Try adding -DBUILD_SHARED_LIBS=Yes to glfw's cmake options, and optionally -DGLFW_BUILD_EXAMPLES=No if they fail to build. This solved this problem for me.

[brendanzab]

@bvssvni Did this work for you?

[bvssvni]

I recompiled GLFW without the fPIC flag and copied one of the C examples (GLBoing) to another folder. It works with the pkg-config instructions:

cc `pkg-config --cflags glfw3` -o myprog myprog.c `pkg-config --static --
libs glfw3` -lGLU

glfw-rs fails with the same error message. I believe if I add the fPIC flag back to GLFW it should link properly. I can reproduce the error on my computer. It could be something about the way Rust links libraries that fails on my computer or the C compiler, but the simplest fix seems to just add fPIC to GLFW. If there is a bug in glfw-rs I have no idea of what that could be.

cc --version
cc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2

rustc --version
rustc 0.10-pre (ee8f45e 2014-02-18 13:41:49 -0800)
host: x86_64-unknown-linux-gnu

[HildarTheDorf]

I can add my experiences here.

there seems to be 2 issues, it seems that glfw's static libs do not by default include -fPIC (meaning the glfw-rs .so can not be built). However, there is also weirdness around the fact that the shared lib is named glfw, and the static lib named glfw3 (on linux. Everywhere else it is only glfw3).

My fix was to add -fPIC to glfw's compile flags, then install only the static libs so that pkg-config returned 'glfw3'. Hacky but effective.

[brendanzab]

@elmindreda Should the glfw static libs include -fPIC?

[aiwenar]

@bjz, @HildarTheDorf From what I know they should not, because -fPIC is used to generate relocatable code, while static libraries are intended to store non-relocatable code which can be included into a binary.

@HildarTheDorf That's probably because version of shared library is stored in file and, by convention, as file extension after '.so', while static libs are just archives with code objects. This also lets you easily choose which one you want to link against.

[HildarTheDorf]

@aiwenar I understand 'why' the filename was chosen to be different, it just causes weirdness when you have both types of library installed.

Perhaps the solution would be to not build a .so out of glfw3.a, just build the .rlib? (You can't use the .so easily in a program if you use gl-rs, since gl-rs doesn't provide a .so (by default) and you can't seem to make rustc use both static and dynamic libraries at the same time. Plus the rust abi is liable to break regularly until rustc gets closer to 1.0). Maybe move the .so to a "make shared" rule?

[aiwenar]

@HildarTheDorf Sorry, I must have misunderstood your comment. Nevertheless it's not weird to have both types installed, as it's common to include .a in development version of library in case developer would like to link it statically.

As to the solution, which you are proposing, it may indeed work because it wouldn't require glfw to be present in the system while building glfw-rs, and thus leaving the choice between static and shared version of glfw to the user. What do you think about it @bjz?

[brendanzab]

@aiwenar So you think a make shared rule would be good?

[brendanzab]

By the way, what does pkg-config --libs glfw3 give you? Does it include -fPIC?

[bvssvni]

$ pkg-config --libs glfw3
-L/usr/local/lib -lglfw3

No -fPIC here.

[brendanzab]

Is this still an issue?

[cparkerdev]

I'm a little late but I just ran into this same issue on SteamOS, compiling glfw with the line below fixed the issue.

sudo cmake -G "Unix Makefiles" -DBUILD_SHARED_LIBS=on -DCMAKE_INSTALL_PREFIX=/usr

[bvssvni]

I'm using OSX now, so this is no longer an issue for me.

[Binero]

I suggest this can be closed?

[hannobraun]

I've had this exact problem after upgrading to the latest Rust nightly yesterday. I think this PR is to blame: rust-lang/rust#16340

I worked around it by compiling GLFW with -fPIC as suggested by @bvssvni :

It works! I edited 'CMakeCache.txt' in the GLFW source to:

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=-fPIC

Recompiled and reinstalled, it now links propertly with glfw-rs

The problem occurs when using glfw-rs via Cargo, but I've also confirmed that it happens when running the glfw-rs examples. The platform is Ubuntu 14.04 64-bit:

$ uname -a
Linux hanno-Vostro-3360 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Has anyone else experienced this problem with a current Rust nightly?

[thestinger]

Static libraries need to be built with -fPIE to support position independent executables (ASLR). Using the static library in a dynamic library requires -fPIC, which is a superset of -fPIE. If your distribution has static libraries without ASLR support, that's a security bug you should take up with them. Alternatively, if you don't care about security, you can pass -C relocation-model=dynamic-no-pic to rustc to disable ASLR.

[hannobraun]

The GLFW I used didn't come with my distribution, I compiled it myself.
@thestinger Are you saying that the GLFW build system should compile swith -fPIE by default? Do you see this as a bug I should report with the GLFW project?

[thestinger]

Supporting ASLR by default in their static libraries (by passing -fPIE) would be a good choice. You could try requesting it upstream but they aren't necessarily going to be interested.

[hannobraun]

@thestinger Thanks for the information, that makes things clearer! I'll contact upstream later to see what they say about it.

[AnthIste]

Also worked for me: http://stackoverflow.com/a/22063830/761648

Add the following to CMakeLists.txt:

IF(CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64")
    ADD_DEFINITIONS(-fPIC)
ENDIF(CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64")

[elmindreda]

GLFW master now builds static and shared libraries alike with -fPIC.