Menu ▾ ▴

#125 symbol conflict with libuuid

branch-1.6.x
closed
Nick Leverton
uuid (1)
5
2017-01-21
2015-02-25
Stepan Salenikovich
No

libupnp contains a function called "uuid_unpack" in the file uuid.h/.c

The library called "libuuid" has a function of the same name:
https://sourceforge.net/p/libuuid/code/ci/master/tree/unpack.c

When both are statically linked in a project, there is a naming conflict between the two functions.

Is it possible prepend this (and possibly the other) function with something like "libupnp_" to avoid this symbol conflict?

Related

Bugs: #125

Discussion

  • Adrien Béraud

    Adrien Béraud - 2015-03-31

    Here is a patch to fix the issue.

    uuid_ methods are renamed to uuid_upnp_
    This makes sense as the structure was already named uuid_upnp.

     
    uuid_upnp.patch

  • Nick Leverton

    Nick Leverton - 2015-04-18

    I would prefer to see the names become upnp_uuid_ rather than uuid_upnp. Most other functions and variables take this pattern.

    There are at least two dependent packages which reference these uuid_ functions, djmount and gmediaserver. So speaking with my Debian packaging hat on we would have to schedule this change to a major version bump.

     

  • Marcelo Roberto Jimenez

    Marcelo Roberto Jimenez - 2016-01-07

    Nick,

    Do you want me to commit this patch with your suggested name change? I have no problems with calling this new release 1.8 or maybe 1.10, since there has been some confusion about 1.8 beeing the master branch.

    Regards,
    Marcelo.

     

  • Nick Leverton

    Nick Leverton - 2016-01-16

    Hi Marcelo, the patch looks fine. We could possibly use 'weak' pragmas to alias the old names but in a way that other libraries can override. This would let us keep 1.6.x ABI compatibility. I'll have a try once I've got some Debian updates done.

     

    • Nick Leverton

      Nick Leverton - 2016-01-18

      I've done a test and I think this may be a non-problem. I have a simple
      program which statically links both libuuid.a and libupnp.a and there is
      no conflict of symbols between them. The uuid_unpack symbol is internal
      to both libraries, neither of them has it in their public header files,
      and neither of them exports it.

      Please can the OP give more details of their build environment -
      Makefiles etc - so that I can understand how the problem is arising and
      try to reproduce it ? It may be there is a better solution than blindly
      renaming private routines.

      In the meantime I'd suggest we defer this patch and the API/ABI change.

      Nick

       

  • Stepan Salenikovich

    Stepan Salenikovich - 2016-01-18

    Hi, I retested and I still have the issue without the patch:

    /home/ssalenikovich/projects/ring-daemon/contrib/x86_64-linux-gnu/lib/libupnp.a(libupnp_la-uuid.o): In function `uuid_unpack':
uuid.c:(.text+0x21f): multiple definition of `uuid_unpack'
/home/ssalenikovich/projects/ring-daemon/contrib/x86_64-linux-gnu/lib/libuuid.a(libuuid_la-unpack.o):unpack.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

    We're having this issue in the Ring project: https://ring.cx/
    We use a contrib system (taken from VLC) to build dependencies from source if they don't exist on the target system and link them statically. This happens when both upnp and uuid are built and linked this way... I will try to reproduce with a simple example when I have time, but you can take a look at our build files by cloning the repo here:
    git clone https://gerrit-ring.savoirfairelinux.com/ring-daemon

    build instructions:
    https://projects.savoirfairelinux.com/projects/ring-daemon/wiki/BuildLinux

    thanks,
    -stepan

     

  • Nick Leverton

    Nick Leverton - 2016-01-23

    Hi Stepan,

    Thanks for the very clear build instructions. I've run through a build on Debian Sid and I don't get the error you do. In that environment, libuuid does contain the uuid_unpack symbol but libupnp still does not export it.

    Could you attach the output of the following please so I could compare with mine ?
    $ nm contrib/*/lib/libupnp.a

    Also, what platform are you getting the error on ?

    Thanks
    Nick

     

  • Nick Leverton

    Nick Leverton - 2016-01-23

    Also if I could make a contribution, in your contrib/ build, depending on locally installed TLS cert availability, wget may fail on https URLs. Could I suggest the attached patch for ring-daemon ? This option is available since wget 1.10 which introduced the stricter TLS checks that fail on Debian, so the option should work on most current distros.

     
    ring-daemon-wget-no-check-cert.patch

  • Marcelo Roberto Jimenez

    Marcelo Roberto Jimenez - 2017-01-21
    • status: open --> closed
    • assigned_to: Nick Leverton
     
MongoDB Logo MongoDB