3
votes

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'
2
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
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
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 stackoverflow.com/questions/31867741/… - alvits
@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
It is a dependency issue. Try placing -lz before -lgio-2.0. - alvits

2 Answers

0
votes

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.

0
votes

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