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.
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.
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.