1. Forum
  2. USENET
  3. muc.lists.freebsd.ports

  • How do I avoid using LD_PRELOAD

    From Nikolaj Thygesen@mailinglist@diamondbox.dk to muc.lists.freebsd.ports on Sun May 31 21:09:23 2026
    From Newsgroup: muc.lists.freebsd.ports

    In lang/swipl the .so:

    /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so

    ... is linked with:

    USES = localbase:ldflags
    LIB_DEPENDS = libossp-uuid.so:misc/ossp-uuid

    ... which works fine build-time, and running:

    readelf -d /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so

    ... returns:

    Dynamic section at offset 0x1530 contains 23 entries:
    Tag Type Name/Value
    0x0000000000000001 (NEEDED) Shared library: [libstdthreads.so.0]
    0x0000000000000001 (NEEDED) Shared library: [libossp-uuid.so.16]
    0x0000000000000001 (NEEDED) Shared library: [libc.so.7]

    ... though the order doesn't seem to matter. At runtime Lldb shows all libs loaded fine, but when calling e.g. read_uuid() the program crashes when calling libc.read_uuid() in place of ossp-uuid.read_uuid() due to a name clash. I can "fix" this by doing:

    LD_PRELOAD=/usr/local/lib/libossp-uuid.so <program-using-uuid's>

    ... but this seems like an unfortunate situation. Is there a more proper solution to this situation? I see a few other ports LIB_DEPENDING on the same port, and I wonder how they can work!?

    Br Nikolaj


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Konstantin Belousov@kostikbel@gmail.com to muc.lists.freebsd.ports on Sun May 31 22:23:02 2026
    From Newsgroup: muc.lists.freebsd.ports

    On Sun, May 31, 2026 at 09:09:23PM +0200, Nikolaj Thygesen wrote:
    In lang/swipl the .so:

    /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so

    ... is linked with:

    USES = localbase:ldflags
    LIB_DEPENDS = libossp-uuid.so:misc/ossp-uuid

    ... which works fine build-time, and running:

    readelf -d /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so

    ... returns:

    Dynamic section at offset 0x1530 contains 23 entries:
    Tag Type Name/Value
    0x0000000000000001 (NEEDED) Shared library: [libstdthreads.so.0]
    0x0000000000000001 (NEEDED) Shared library: [libossp-uuid.so.16]
    0x0000000000000001 (NEEDED) Shared library: [libc.so.7]

    ... though the order doesn't seem to matter. At runtime Lldb shows all libs loaded fine, but when calling e.g. read_uuid() the program crashes when calling libc.read_uuid() in place of ossp-uuid.read_uuid() due to a name clash. I can "fix" this by doing:

    LD_PRELOAD=/usr/local/lib/libossp-uuid.so <program-using-uuid's>

    ... but this seems like an unfortunate situation. Is there a more proper solution to this situation? I see a few other ports LIB_DEPENDING on the same port, and I wonder how they can work!?

    What matter is the order of the global NEEDED graph for the binary.
    If there is some library that depends on libc.so.7 (or libc.so.7 itself)
    which is loaded in the global NEEDED order before libossp-uuid.so.16,
    then it gets a priority in resolving the symbols.


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Nikolaj Thygesen@mailinglist@diamondbox.dk to muc.lists.freebsd.ports on Sun May 31 21:32:24 2026
    From Newsgroup: muc.lists.freebsd.ports

    On Sun, 31 May 2026 22:23:02 +0300
    Konstantin Belousov <kostikbel@gmail.com> wrote:

    On Sun, May 31, 2026 at 09:09:23PM +0200, Nikolaj Thygesen wrote:
    In lang/swipl the .so:

    /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so

    ... is linked with:

    USES = localbase:ldflags
    LIB_DEPENDS = libossp-uuid.so:misc/ossp-uuid

    ... which works fine build-time, and running:

    readelf -d /usr/local/lib/swipl/lib/amd64-freebsd/uuid.so

    ... returns:

    Dynamic section at offset 0x1530 contains 23 entries:
    Tag Type Name/Value
    0x0000000000000001 (NEEDED) Shared library:
    [libstdthreads.so.0] 0x0000000000000001 (NEEDED) Shared
    library: [libossp-uuid.so.16] 0x0000000000000001 (NEEDED)
    Shared library: [libc.so.7]

    ... though the order doesn't seem to matter. At runtime Lldb shows
    all libs loaded fine, but when calling e.g. read_uuid() the program
    crashes when calling libc.read_uuid() in place of
    ossp-uuid.read_uuid() due to a name clash. I can "fix" this by
    doing:

    LD_PRELOAD=/usr/local/lib/libossp-uuid.so
    <program-using-uuid's>

    ... but this seems like an unfortunate situation. Is there a more
    proper solution to this situation? I see a few other ports
    LIB_DEPENDING on the same port, and I wonder how they can work!?

    What matter is the order of the global NEEDED graph for the binary.
    If there is some library that depends on libc.so.7 (or libc.so.7
    itself) which is loaded in the global NEEDED order before
    libossp-uuid.so.16, then it gets a priority in resolving the symbols.


    ... that makes sense - so what can I expect from "USES=localbase:ldflags"? From your reply it sound slike there's no workaround?


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.22a-Linux NewsLink 1.2