- December 18, 2011 at 7:11 am #30713
I’m trying to link PVRTexLib into a shared library (specifically a Python extension module) on 64-bit Linux. Specifically, this is 64-bit Ubuntu 10.04. When I link, gcc gives me the following error message:
/usr/bin/ld: Ext/PVRTexLib_2.09.29.0678/Linux_x86_64/libPVRTexLib.a(pvr_utils.o): relocation R_X86_64_32S against `.rodata’ can not be used when making a shared object; recompile with -fPIC
Ext/PVRTexLib_2.09.29.0678/Linux_x86_64/libPVRTexLib.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
A cursory googling suggests this is because pvrtexlib was not compiled with the -fPIC option. A project from earlier this year indicates that PVRTexLib used to be compatible with shared libraries: https://github.com/media-explorer/gdk-pixbuf-texture-tool/blob/master/Makefile Today that project does not link. It gives the same error as above.
Can we get a build of PVRTexLib with -fPIC? Or is there a workaround?
chadaustin 2011-12-18 07:11:40June 24, 2012 at 7:01 pm #35331
I just want to second this request. It seems impossible to link the PVRTexLib to a shared library on 64 bit linux unless the sources are recompiled with fPIC. Furthermore, this means it’s impossible to use PVRTexLib via Java through JNI, since doing so requires linking against a shared library. This is a serious limitation that seems pretty easy to fix! Hope to see it soon, or a workaround. Thanks,R.June 25, 2012 at 10:02 am #35332
I’ve looked into this now and should be able to enable it for the next release of PVRTexLib which should be available in a few months time. I do need to do a few more tests to make sure this all works properly, so I can’t make solid guarantees at this point – it doesn’t sound like it would be a problem though.
TobiasJune 26, 2012 at 5:47 am #35333
Thanks Tobias for the quick response! Looking forward to the release,R.October 2, 2013 at 6:53 am #35334
Any updates on this?
Seems to be still broken with the latest 3.1 version:
$ gcc /tmp/test.c -shared /opt/Imagination/PowerVR/GraphicsSDK/PVRTexTool/Library/Linux_x86_64/Static/libPVRTexLib.a /usr/bin/ld: /tmp/ccrBZDio.o: relocation R_X86_64_PC32 against symbol `pvrtexture::CPVRTexture::CPVRTexture(void const*)’ can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit statusOctober 2, 2013 at 11:19 am #35335
PVRTexLib is definitely being compiled with -fPIC, and has been for a long time – I just checked our builds to make sure there wasn’t a regression. Also PVRVFrame’s dynamic libraries link the static PVRTexLib into them, so it’s certainly working for us. I’m not really sure what else would be the problem I’m afraid 🙁
TobiasOctober 2, 2013 at 11:23 am #35336
One of my colleagues just noticed that it’s actually complaining about some temporary object “ccrBZDio.o”, which wasn’t the same as the original error in this post. It might be useful to figure out where this object has come from, because it’s certainly not part of PVRTexLib.