|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 backend||Assignee:||cairo-bugs mailing list <cairo-bugs>|
|Status:||RESOLVED NOTOURBUG||QA Contact:||cairo-bugs mailing list <cairo-bugs>|
|i915 platform:||i915 features:|
Standard error output of the compilation
Standard output of the compilation
Configure log script
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: https://code.launchpad.net/~gnome-win32/buildows/module-sets 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 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.