Bug 14323

Please attach the relevant parts of the output from the configure script and from building. Search for messages mentioning "shared" or "DLL", for instance.

Created attachment 14073 [details]
Standard error output of the compilation

Created attachment 14074 [details]
Standard output of the compilation

Created attachment 14075 [details]
Configure log script

This is all the output that I have from the build process. I see nothing relevant that would bring me to know what's going on.

Any ideas?

Just replaced cairo 1.4.14 for 1.2.6, this version produces the dll.

Created attachment 14077 [details]
Makefile output

Created attachment 14078 [details]
Makefile output under src/

I have found this issue executing make under src/ which leads me to think that it's not a cairo problem:


*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/aruiz/gtk-target/lib/libz.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Ah yes. I love those libtool messages. "Warning: linker path does not have real file for library -lfoobar". I don't remember exactly, but I think the problem in cases like this is that 1) either you have a libfoobar.la file and it would work better without, or 2) you only have a libfoobar.a (or libfoobar.dll.a) and it would work better with a libfoobar.la, too.

(Mind you, that experience is from native builds. But probably the same holds for cross builds.)

I think 1) is the case, and the solution is to not use the original install target folder of (for instance) zlib when building a library that depends on zlib, but just a "extracted" installation that has been re-installed in some different prefix, containing just the .dll.a import library, and no .la libtool archive. Libtool archives can be a pain in the posterior.

Well, I finally discovered the problem. The zlib version I built wasn't installing the shared library which led to this problem.

This is not a cairo bug really, sorry for that.