Bug 4195

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.