3

The Short Version

Linking my executable against several libraries, including libgio-2.0.so.0.4800.1 (libgio-2.0.so) and libz.so.1.2.8 (libz.so), I get two unresolved symbols - deflateSetHeader@ZLIB_1.2.2 and inflateGetHeader@ZLIB_1.2.2. Neither symbol is defined in libz.so, but inflateGetHeader@@ZLIB_1.2.2 and deflateSetHeader@@ZLIB_1.2.2 are:

readelf -s libz.so|grep Header
    63: 00007991    28 FUNC    GLOBAL DEFAULT   12 inflateGetHeader@@ZLIB_1.2.2
    98: 00003319    24 FUNC    GLOBAL DEFAULT   12 deflateSetHeader@@ZLIB_1.2.2
   367: 00003319    24 FUNC    GLOBAL DEFAULT   12 deflateSetHeader
   386: 00007991    28 FUNC    GLOBAL DEFAULT   12 inflateGetHeader

Other symbols referenced in libgio are successfully resolved by libz, but not these two.

The Long Version

I'm cross-compiling from a Windows host (Xilinx SDK 2016.1 (Eclipse), toolchain "arm-linux-gnueabihf") for a Zynq 7010-based target (krtkl.com) running 32-bit Ubuntu 14.04 with a Linaro 4.4 kernel.

Both the host and target platforms are given, in case you feel the need to ask why I'm doing it that way.

The procedure for using an external shared library is this: download, configure and build library on the target (unless the library already exists on the target), then copy include and library (libabc.so.x.y.z) files to a bespoke project directory on the host, rename libabc.so.x.y.z to abc.so, and set the library path to project directory and library name to abc (i.e. gcc ... -L<project dir> -labc).

I'm using this procedure to include GLib (among others) in my project. GLib (libglib.so) requires GIO (libgio.so), which in turn requires (among others) ZLIB (libz.so).

These libraries are built from source: glib-2.48.1 (including gio, gobject, and gmodule), libffi-3.2.1, zlib-1.2.8. Others are from the Ubuntu distro.

When I run the cross-compiler on Windows ("Project|Build All" in Eclipse), all goes according to plan - libgio-2.0.so, libglib-2.0.so, gobject-2.0.so, libffi.so, libgmodule-2.0.so, libdl.so, libpcre.so, libresolv-2.19.so and libz.so satisfy all external references except deflateSetHeader@ZLIB_1.2.2 and inflateGetHeader@ZLIB_1.2.2.

readelf output (see above) shows similar, but not identical, symbols available in libz.so. I've seen a few mentions of similar problems while searching on-line, but the resolution always has to do with finding an outdated version of ZLIB - not a possibility given my development environment.

Both libgio and libz are well-established libraries in wide use - this can't be a bug, right?

I'm out of ideas - has anyone encountered this or anything similar?

[UPDATE]

gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)

By request, here are example compiler and linker commands emitted by Eclipse:

19:53:13 **** Auto Build of configuration Debug for project Project_2 ****
make -j8 all 
'Building file: ../src/Project.c'
'Invoking: ARM v7 Linux gcc compiler'
arm-linux-gnueabihf-gcc -DCONFIGURATION_DEBUG -Wall -O0 -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -g3 -I"C:\Users\Nick\XSDK\Workspace\snickerdoodle_bsp\ps7_cortexa9_0\include" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir1" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir2" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir3" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir4" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir5" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir6" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir7" -I"C:\Users\Nick\XSDK\Workspace\Project_2\src\Dir8" -I"C:\Users\Nick\XSDK\Workspace\LibXml2\include" -I"C:\Users\Nick\XSDK\Workspace\LibXml2\include\libxml" -I"C:\Users\Nick\XSDK\Workspace\GLibC\include" -c -fmessage-length=0 -MT"src/Project.o" -MMD -MP -MF"src/Project.d" -MT"src/Project.o" -o "src/Project.o" "../src/Project.c"
'Finished building: ../src/Project.c'

'Invoking: ARM v7 Linux gcc linker'
arm-linux-gnueabihf-gcc -L"C:\Users\Nick\XSDK\Workspace\LibXml2\lib" -L"C:\Users\Nick\XSDK\Workspace\GLibC\lib" -o "Project_2.elf"  <all the .o files> -lpthread -lm -lxml2 -llzma -lgio-2.0 -lglib-2.0 -lgobject-2.0 -lffi -lgmodule-2.0 -ldl -lpcre -lresolv-2.19 -lz
c:/xilinx/sdk/2016.1/gnu/aarch32/nt/gcc-arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabihf/4.9.2/../../../../arm-linux-gnueabihf/bin/ld.exe: warning: libz.so.1, needed by C:\Users\Nick\XSDK\Workspace\GLibC\lib/libgio-2.0.so, not found (try using -rpath or -rpath-link)
C:\Users\Nick\XSDK\Workspace\GLibC\lib/libgio-2.0.so: undefined reference to `deflateSetHeader@ZLIB_1.2.2'
C:\Users\Nick\XSDK\Workspace\GLibC\lib/libgio-2.0.so: undefined reference to `inflateGetHeader@ZLIB_1.2.2'
binky
  • 532
  • 2
  • 8
  • most probably, your SDK or your final image already contain parts of the libraries you manually add. Also, thanks for clarifying platforms are given, but don't do this to yourself. Rather run the SDK in a Linux VM. – Marcus Müller Aug 05 '16 at 20:52
  • Thanks, Marcus. This issue notwithstanding, the setup works quite well. If I don't include -lz, I get many more unresolved references, so I'm pretty sure they're being resolved from the library I'm adding. There's really nowhere else for them to come from. – binky Aug 05 '16 at 22:56
  • Could you possibly update your post to include the compilation and linking CLI you are running? Sometimes the issue is just with the order of the parameters to the compiler http://stackoverflow.com/questions/31867741/does-the-order-in-which-libraries-appear-on-the-gcc-command-line-matter – alvits Aug 06 '16 at 00:08
  • @alvits - Thanks, I've edited my post to include an example compiler command and the linker command. I'm not very hopeful that the problem might be found there, but I do appreciate your looking! Thanks! – binky Aug 06 '16 at 02:58
  • It is a dependency issue. Try placing `-lz` before `-lgio-2.0`. – alvits Aug 06 '16 at 03:07
  • @alvits - Thanks again. Tried it - no difference. Can you explain your reasoning? – binky Aug 06 '16 at 19:47
  • The order does matter. check this out as an example http://stackoverflow.com/questions/9934549/very-strange-linker-behavior. Can you run the following command `ldd -r /path/to/libgio-2.0.so`? See if it complains of the same issue as your linker does. – alvits Aug 06 '16 at 23:06
  • If you move `-lz` between `-lpthread` and `-lm` does it show the same error or a new error? – alvits Aug 06 '16 at 23:21
  • @alvits - Found it! It turned out not to be an ordering issue, but as is often the case, simply discussing things with someone who has a different point of view forces you to look at things differently. What you couldn't have known (and what I had forgotten) was the presence of a static version of libz in another project. Your questions were what lead me to the answer. Thanks again! – binky Aug 08 '16 at 19:19

2 Answers2

0

It turned out to be what a colleague used to call an IO error (for Incompetent Operator). There was a second, static copy of zlib (libz.a) in another project that was competing with the shared version. A little rejiggering of that project, and all compiles nicely now.

binky
  • 532
  • 2
  • 8
0

by removing -lz from LDFLAGS/LDLIBS, it got resolved for me

Vipin Nagar
  • 105
  • 1
  • 4