Bug 14323

Summary: Cross compiling cairo 1.4.14 with MinGW32 from linux doesn't produce any dll files
Product: cairo Reporter: Alberto Ruiz <aruiz>
Component: win32 backendAssignee: cairo-bugs mailing list <cairo-bugs>
Status: RESOLVED NOTOURBUG QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: tml
Version: 1.4.14   
Hardware: x86 (IA32)   
OS: Windows (All)   
i915 platform: i915 features:
Attachments: Standard error output of the compilation
Standard output of the compilation
Configure log script
Makefile output
Makefile output under src/

Description Alberto Ruiz 2008-01-31 18:00:46 UTC
I'm cross compiling cairo with the jhbuild modulesets and jhbuildrc file found in this bazaar branch:


Cairo builds and installs without any errors whatsoever, however, it doesn't generates any .dll files.

I don't even know how to start to come up with a fix, any help would be welcome.
Comment 1 Tor Lillqvist 2008-01-31 23:20:43 UTC
Please attach the relevant parts of the output from the configure script and from building. Search for messages mentioning "shared" or "DLL", for instance.
Comment 2 Alberto Ruiz 2008-02-01 11:15:35 UTC
Created attachment 14073 [details]
Standard error output of the compilation
Comment 3 Alberto Ruiz 2008-02-01 11:16:05 UTC
Created attachment 14074 [details]
Standard output of the compilation
Comment 4 Alberto Ruiz 2008-02-01 11:16:52 UTC
Created attachment 14075 [details]
Configure log script
Comment 5 Alberto Ruiz 2008-02-01 11:18:09 UTC
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?
Comment 6 Alberto Ruiz 2008-02-01 11:35:56 UTC
Just replaced cairo 1.4.14 for 1.2.6, this version produces the dll.
Comment 7 Alberto Ruiz 2008-02-01 11:47:50 UTC
Created attachment 14077 [details]
Makefile output
Comment 8 Alberto Ruiz 2008-02-01 11:56:47 UTC
Created attachment 14078 [details]
Makefile output under src/
Comment 9 Alberto Ruiz 2008-02-01 12:06:41 UTC
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.
Comment 10 Tor Lillqvist 2008-02-01 12:16:35 UTC
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.
Comment 11 Alberto Ruiz 2008-02-01 19:48:24 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.