New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recreate libfmod.so.6 symlinks #304

Merged
merged 1 commit into from Nov 30, 2017

Conversation

Projects
None yet
2 participants
@cirosantilli
Contributor

cirosantilli commented Oct 20, 2017

Those symlinks were removed in 7c9d86e
but they are actually need.

Doing readelf -d libfmod.so, shows:

0x000000000000000e (SONAME)             Library soname: [libfmod.so.6]

and this magic SONAME ELF field must be getting used by ld, man ld says:

-soname=name
    When an executable is linked with a shared object which has a DT_SONAME field,
    then when the executable is run the dynamic linker will attempt to load the shared
    object specified by the DT_SONAME field rather than the using the file name given to the linker.

libfmod is a closed source blob, the symlink looks like the only solution.

Fixes:

Tested in Ubuntu 17.04.

Recreate libfmod.so.6 symlinks
Those symlinks were removed in 7c9d86e
but they are actually need.

Doing readelf -d libfmod.so, shows:

    0x000000000000000e (SONAME)             Library soname: [libfmod.so.6]

and this magic SONAME ELF field must be getting used by ld, man ld says:

    -soname=name
        When an executable is linked with a shared object which has a DT_SONAME field,
        then when the executable is run the dynamic linker will attempt to load the shared
        object specified by the DT_SONAME field rather than the using the file name given to the linker.

libfmod is a closed source blob, the symlink looks like the only solution.

Fixes:

- cocos2d/cocos2d-x#15137
- cocos2d/cocos2d-x#16511
- cocos2d/cocos2d-x#17917

Tested in Ubuntu 17.04.
@minggo

This comment has been minimized.

Contributor

minggo commented Oct 23, 2017

@cirosantilli did you modify it manually? Should we do it manually in future if updating fmod.

@cirosantilli

This comment has been minimized.

Contributor

cirosantilli commented Oct 23, 2017

@minggo I don't understand, I didn't modify the binary, only added the symlink from libdmod.so.6 to libfmod, which should be kept during upgrades.

@minggo

This comment has been minimized.

Contributor

minggo commented Nov 30, 2017

What i mean is that when updating libfmod.so in future, should modify libfmod.so manually? If so, then it is hard to remember it.

@cirosantilli

This comment has been minimized.

Contributor

cirosantilli commented Nov 30, 2017

@minggo no, I didn't modify the binary. If you have the symlink, you don't need to modify the binary.

The problem is that the currenty binary points to libfmod.so.6 which is not found. With the symlink named libfmod.so.6, it finds the symlink and works.

@minggo

This comment has been minimized.

Contributor

minggo commented Nov 30, 2017

It is strange, the PR shows it modifies the binary file: https://github.com/cocos2d/cocos2d-x-3rd-party-libs-bin/pull/304/files

@minggo

This comment has been minimized.

Contributor

minggo commented Nov 30, 2017

Oh, it is my fault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment