I want to know about the zlib.h open source header file implementation.
I want to know what exactly the statement below means:
`Z_VERSION_ERROR` if the zlib library version (zlib_version) is incompatible
with the version assumed by the caller (`ZLIB_VERSION`).
I am working on an ARM arch64 platform machine and using this open source header in our build. It is returning Z_VERSION_ERROR.
I am trying to build an executable called 'denzip' using the library libenz.a, which I created with the zlib source.
PS: 'libdenz.a' is a library which I created from the standard library 'libz.a', from the zlib source. The reason is that we have a requirement to rename some symbols in original library (libz.a).
Build command:
common/pkgs/gcc/v6.3.0/bin/gcc -L/usr/X11R6/lib -O2 -DUSE_FLEX -Wall -Wno-char-subscripts -fPIC -DLINUX -DG_DISABLE_CONST_RETURNS -fno-strict-aliasing -o Release/tools/denzip -Wl,-E Release/tools/denzip.o -L/home/clib/extlibs/Lnx/lib -ldenbase -ldenz -ldenbase -ldl -lm -lc
I have the library 'libdenz.a' is at path '/home/clib/extlibs/Lnx/lib'.
After executable 'denzip' is created. When I try to use that executable I get:
denzip -c trctotb.tcl
Error: *** Error: Error in trctotb.tcl compression: bad library version
*** Error: trctotb.tcl: aborting compression
Source:
int rc;
rc = DenZ_deflateInit( &zstream, Z_DEFAULT_COMPRESSION );
switch ( rc ) {
case Z_MEM_ERROR:
reportZError( "insufficient memory", contentType,
"compression", &zstream );
return FALSE;
case Z_VERSION_ERROR:
printf("The integer is %d\n", zlib_version);
reportZError( "bad library version", contentType,
"compression", &zstream );
return FALSE;
}
Z_VERSION_ERROR is coming from zlib.h
It means that the header files zlib.h and zconf.h are from a different version of zlib than the libz.so or libz.a library binary that you are linking to.
Print ZLIB_VERSION and the result of zlibVersion() to see the versions of the header and library respectively.
Related
I'm trying to use a C library called quirc in my C project. So far, I have generated a libquirc.dylib.1.0 by modifying the Makefile which was using Linux .so files.
quirc/helloquirc.c
#include <quirc.h>
#include <stdio.h>
int main() {
struct quirc *qr;
qr = quirc_new();
if (!qr) {
printf("Failed to allocate memory");
}
quirc_destroy(qr);
return 0;
}
I've created the above source file at the root of the repository. I'm using the following command to compile it:
gcc helloquirc.c -lquirc -L. -Ilib -o helloquirc
To my understanding the -l flag specifies the name of the dynamic library, the -L flag specifies the location of the dynamic library, the -I flag specifies the location of the header files, and -o specifies the name of the executable.
When I run this command I get the following error:
ld: library not found for -lquirc
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I changed the Makefile by using this line
.PHONY: libquirc.dylib
libquirc.dylib: libquirc.$(LIB_VERSION).dylib
libquirc.$(LIB_VERSION).dylib: $(LIB_OBJ)
$(CC) -shared -dynamiclib -o $# $(LIB_OBJ) $(LDFLAGS) -lm
and changing other instances of .so.$(LIB_VERSION) to .$(LIB_VERSION).dylib
Something is wrong with the way quirc was built. The correct library name would be something like libquirc.1.0.dylib with a symlink named libquirc.dylib.
It looks like quirc has a handwritten makefile instead of using something sensible like gyp or cmake. Handwritten makefiles are just fine as long as you're not trying to build shared libraries on multiple platforms.
However, if you are just compiling it yourself, you may find things simpler if you just use a static library instead. There is no point in having a shared library if you are not sharing it with anybody (if no other programs are using the same exact copy of libquirc).
My program uses the GNU Multiple Precision Arithmetic Library to deal with numbers of an arbitrary size. I successfully compile it using GCC with:
gcc main.c -o diff -g -lgmp
However, when I try to use the MinGW crosscompiler compiler, I get the following error:
i686-w64-mingw32-gcc main.c -o diff.exe -g -lgmp
main.c:3:46: fatal error: gmp.h: No such file or directory
#include <gmp.h>//For files of arbitrary size
I then tried to tell it exactly where the header file was:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
Ok, so I figure now it successfully found the header, but cant find the library. So I tried again:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g -L/usr/lib -lgmp
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
I guess I need to specify the exact files to use, so I tried this:
i686-w64-mingw32-gcc main.c -o diff.exe -I/usr/include -g /usr/lib/libgmp.so
/usr/lib/libgmp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
So, I honestly don't know what to do and I'd really really appreciate your help.
First, a disclaimer: the cross-compiler you are using is neither distributed by, nor supported by MinGW.org, whom I represent; if you are looking for a pre-compiled solution, you should seek it from the distributor of the specific cross-compiler itself.
That said, I can offer the following insight, (which will apply, in general, to any cross-compiler): the headers you find in /usr/include, or in /usr/local/include, and the libgmp.so which you find in /usr/lib, or in /usr/local/lib, are intended for use with your native platform compiler. They are not suitable for, and cannot be used with your MinGW cross-compiler; attempting to do so will surely never work. Thus, you have two options:
Ask your cross-compiler distributor to provide a pre-compiled copy of gmp.dll, (or at the very least, a compatible import library, although you may need the gmp.dll to distribute with your own application anyway), and any associated header files, and/or equivalent statically linkable library, for use with your cross-compiler.
Use your cross-compiler to build gmp.dll yourself, then install it, its associated headers, and perhaps also its associated import library and/or equivalent statically linkable library, into the same prefix-path as the cross-compiler itself.
I'm trying to compile a makefile which includes the following line:
gcc -I. -I/home/usr/Documents/MTV/include -ggdb3 -Wall -O2 -o ascii2bin.c \
-L. -L../lib -lmatrix -lseq_io -lpic -lm
And this is what I get:
../lib/libmatrix.a: file not recognized: File format not recognized
collect2: ld returned 1 exit status
Any idea on what might happen to libmatrix.a? How can I read what's inside libmatrix.a? I tried using the 'ar -t' command, but it also says file format not recognized.
The project was compiled on Cygwin before by others, and now I'm using ubuntu gcc to try to redo it, could this be the problem?
A library file built for cygwin will not work on linux.
The library itself must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which it is intended to be used.
Cygwin tries to be source compatible with Linux, so if you have the source rebuilding may be straightforward. But it is not binary-compatible, and libraries are basically binary building blocks with metadata to permit linking them together.
With gcc in ubuntu I used this command to compile my source code:
gcc 1.c -L. -lagent -lm -lpthread -o 1
but I got this error:
/usr/bin/ld: skipping incompatible ./libagent.so when searching for -lagent
/usr/bin/ld: cannot find -lagent
collect2: ld returned 1 exit status
How can I solve this?
The linker is telling you that the file ./libagent.so exists, but isn't in the appropriate format.
It could be an empty file, or built for 32-bit instead of 64-bit, or it could be a symlink pointing to the wrong version.
Let's look at your command line parameters first.
gcc 1.c -L. -lagent -lm -lpthread -o 1
You call the compiler gcc with the input source code of 1.c and then you specify an additional (link) library path to include the current directory (.) -L.. Then you tell it to link against the agent and pthread libraries, where shared (dynamic) libraries have the default name format of libNAME.so where NAME is replaced with the name. Static libraries have the default file extension .a (from the term archive). Then you specify the output (executable in this case) to be the file 1 (digit one, not the letter 'ell').
/usr/bin/ld: skipping incompatible ./libagent.so when searching for -lagent
This is the linker (ld) telling you that the file ./libagent.so (it found presumably in the current directory) is not a valid shared library format as it was expecting. This could be for a different machine architecture (x86-64, ARMle, PowerPC, MIPS) or a incompatible library format (I don't know if library files, .so, have any COFF or ELF or PE dependencies or not). Or simply otherwise empty or corrupted (e.g. interrupted output due to errors compiling / linking).
So you normally want to not include your current directory in your linker's search path, unless you have the copy of the library that you have not yet installed (typically to /usr/lib/ or /usr/local/lib/), such as you wrote the library and wish to link test programs to it before you install it.
Debian and Unbuntu-oriented part of the answer:
Normally you want to install shared library's runtime component (often named something like libagent) and the associated development files (most often at least a header file and hopefully a manpage) in the format libagent-dev. RPM based Linux systems use libagent-devel style naming conventions (from memory). So sudo aptitude install libagent-dev should do the trick if that is the package's name.
The problem is this: I wrote a simple program that uses FFMPEG. compile as follows:
gcc -lavcodec -lavformat -lavutil -c test.c
gcc -lavcodec -lavformat -Lavut -o test test.o
Compiled without problems, test file appears, but when you start:
. / test
An error occurs:
. / test: error while loading shared libraries: libavcodec.so.53: cannot open shared object file: No such file or directory
At what ffmpeg was originally built and installed and the file libavcodec.so.53 there. In what may be the problem?
You appear to be linking against libraries in a custom library directory, -Lavut.
Check where your loader looks for the executable's libraries:
ldd ./test
If any of them are in non-standard directories (and ldd indicates that a particular library couldn't be found), append those to the LD_LIBRARY_PATH:
LD_LIBRARY_PATH=/tmp/work/avut ./test
If you like, you can hardcode the library path into the executable with the -rpath linker option, e.g. gcc ... -Wl,-rpath -Wl,/tmp/work/avut.