PVRTexLib: fails to link in .so, 64-bit Linux

This topic contains 6 replies, has 4 voices, and was last updated by  Tobias Hector 4 years ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #30713

    chadaustin
    Member

    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?

    Thanks,

    Chad

    chadaustin2011-12-18 07:11:40

    #35331

    radvani
    Member

    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.
    #35332

    Hi,

    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.

    Thanks,

    Tobias

    #35333

    radvani
    Member

    Thanks Tobias for the quick response! Looking forward to the release,

    R.
    #35334

    dvyukov
    Member

    Hi,

    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 status

    #35335

    Hi Dvyukov,

    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 🙁

    Tobias

    #35336

    Hi Dvyukov,

    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.

    Regards,
    Tobias

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.