After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 668365 - libgdata 0.10.x link error because of exported symbols that don't exist
libgdata 0.10.x link error because of exported symbols that don't exist
Status: RESOLVED FIXED
Product: libgdata
Classification: Platform
Component: YouTube service
0.10.x
Other Solaris
: Normal normal
: ---
Assigned To: libgdata-maint
libgdata-maint
Depends on:
Blocks:
 
 
Reported: 2012-01-20 18:32 UTC by Tim Mooney
Modified: 2012-01-23 19:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim Mooney 2012-01-20 18:32:07 UTC
I'm building libgdata-0.10.1 on x86_64-sun-solaris2.10 with the no-cost Oracle Studio 12.2 toolchain & the standard Solaris linker, ld.

Much like Linux, the ld on Solaris supports linker maps.  Apparently unlike the Linux linker, though, ld objects to a linker map that declares global scope symbols that don't actually exist in any of the object files.  This is results in the following link error when trying to create libgdata:

Undefined                       first referenced
 symbol                             in file
GDATA_YOUTUBE_RATING_TYPE_V_CHIP    gdata/.libs/libgdata.so.13.1.1.exp
GDATA_YOUTUBE_RATING_TYPE_SIMPLE    gdata/.libs/libgdata.so.13.1.1.exp
GDATA_YOUTUBE_RATING_TYPE_MPAA      gdata/.libs/libgdata.so.13.1.1.exp
ld: fatal: Symbol referencing errors. No output written to gdata/.libs/libgdata.so.13.1.1
gmake[2]: *** [gdata/libgdata.la] Error 2
gmake[2]: Leaving directory `/local/src/RPM/BUILD/libgdata-0.10.1'


Examining the code, the linker is correct.  While there are #defines that map each of those to a string, there's no actual symbols (function or variable) with those names.  I'm really surprised that the Linux ld hasn't flagged this as an error as well.
Comment 1 Philip Withnall 2012-01-21 10:37:02 UTC
I'm also surprised that ld didn't warn about it. I guess it just included them in the library as undefined symbols. I tried playing about with linker flags such as --no-allow-shlib-undefined and --error-unresolved-symbols, but they throw errors from libgdata's dependency libraries, so can't be used.

I'll backport the patch to the 0.10.x branch in time for the next 0.10.x release (which might take a while).

commit 2dda90f943b8a4419982d54342e14ffada908bd8
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Sat Jan 21 10:20:44 2012 +0000

    build: Remove some #defines from gdata.symbols
    
    They should never have been in there, and were breaking the build on Solaris
    
    Closes: https://bugzilla.gnome.org/show_bug.cgi?id=668365

 gdata/gdata.symbols |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)
Comment 2 Tim Mooney 2012-01-23 18:33:05 UTC
I'm happy to see your change, but I do have one concern: is there any danger of this ABI change causing problems for anyone on Linux that built 0.10.0 or 0.10.1?

For my personal build needs, since I don't have a previous libgdata from the 0.10.x series, having the ABI change isn't going to cause a problem, but I would hate for an issue I raised to cause unintended issues for Linux.
Comment 3 Philip Withnall 2012-01-23 19:11:34 UTC
I can't see why this should cause a problem for any software: nothing should ever have tried to resolve those symbols in libgdata.so, since any code compiled against libgdata would've substituted them in the preprocessing stage.

That said, my ld knowledge is weak and I could be wrong. If so, I guess people will file bugs as appropriate.