There are a couple problems with poppler-0.4.0 and building shared libraries on Cygwin, where all symbols must be resolved at link time. 1) -no-undefined must be declared in all libpoppler*_la_LDFLAGS 2) libraries on Cygwin aren't .so, so the qt library checks (and POPPLER_QT*_LIBS defines) are not portable. I'm attaching a patch that fixes both problems. FYI, binaries of poppler with glib and qt3 support (I haven't built qt4 yet) are available at the indicated URL.
Created attachment 2993 [details] [review] poppler-0.4.0-1.patch
This patch break qt detection on platforms that don't install static libs. Is it possible to check for either dynamic or static libs or even better look for the DLL on cygwin?
In that case, I suppose there are a few options: 1) just check for libqt-mt.la, but for all we know there could be some platform/distro which doesn't distribute that either; 2) Something like this (since we want to look for the import link library on Cygwin, not the runtime dll): case $target in *-*-*cygwin*) qt_test_library="libqt-mt.dll.a" ;; *) qt_test_library="libqt-mt.so" ;; esac This second option could of course be expanded to cover other arches if necessary.
I know that fedora explicitly deletes .la files, so that's definitely less reliable than test the static libs. The second options looks pretty good though... is the dll name really libqt-mt.dll.a though?
No, that's not the name of the DLL, it's the name of the DLL's import library. In short, Cygwin programs and libraries are PE executables, which depend on the Win32 runtime linker, which only understands PATH and knows nothing about LD_LIBRARY_PATH, symlinks, ELF versioning, and the like. Therefore, DLLs are placed in bin and a import library in lib, for buildtime linking purposes in place of the actual dll (which will be used as first choice when there's both shared and static libs). So therefore, where on Linux you would get (if qt-mt were a regular libtool lib): lib/libqt-mt.a lib/libqt-mt.la lib/libqt-mt.so.3.3.4 (actual library) lib/libqt-mt.so.3 (runtime linker symlink) lib/libqt-mt.so (buildtime linker symlink) on Cygwin, you get: bin/cygqt-mt-3.dll (actual library, not micro-versioned) lib/libqt-mt.a lib/libqt-mt.dll.a (buildtime import library) lib/libqt-mt.la In any case, if you want to know if you can *link* against a shared qt-mt, you still look in lib, just for the .dll.a import library.
Created attachment 11833 [details] [review] poppler-0.6 Cygwin patch New patch for 0.6.
Created attachment 20171 [details] [review] qt3 detection patch New patch for qt3 detection. Patch was originally made against 0.8.4, but applies cleanly to 0.10.1.
Created attachment 20172 [details] [review] 0.10 -no-undefined patch New patch for -no-undefined on Cygwin for 0.10.1.
Created attachment 20173 [details] [review] uint32_t patch On Cygwin, uint32_t is typedef'd as unsigned long in <stdint.h>. Patch originally made against 0.8.4, applies to 0.10.1.
Can you check with a newer poppler? We've got some reports of success.
Comment on attachment 20173 [details] [review] uint32_t patch Cygwin 1.7 (coming out of beta in the next few weeks) has fixed up its types, so the uint32_t patch is no longer necessary. The no-undefined and find-qt3 patches are still good for 0.10.7.
Created attachment 29793 [details] [review] 0.12 -no-undefined patch New -no-undefined patch for 0.12.0.
Commited for 0.12.1
Do you still need the qt3 detection patch ?
(In reply to comment #14) > Do you still need the qt3 detection patch ? Yes.
Ok, after lots of looks to the patch i finally understood it. I've commited it too.
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.