GPGME 1.0.3 Build Problem

[Marcus Brinkmann]

At Thu, 30 Nov 2006 22:17:23 -0600,
"Yaakov S (Cygwin Ports)" <yselkowitz at users.sourceforge.net> wrote:
> > Then, GPGME builds the final library from the thread module, adding
> > the non-installed libgpgme-real.la to the bundle via LIBADD.
> > 
> > Ok, that's not really clean.  The problem is that now the order is
> > messed up: The thread module's symbols get first on the linker command
> > line, then comes the non-installed library using those symbols, then
> > comes the rest.  However, this setup avoids building every file three
> > times, cutting compile time to a third, and it seems to work OK on our
> > main targets (and then some).
> 
> That's not a problem because libtool encloses the noinst libs with
> - -Wl,--{,no-}whole-archive, allowing for just this situation.

Ah, ok.
 
> > Well, considering that it is not totally clean, I don't have a
> > fundamental object to remove the libgpgme-real hack and build each
> > file three times, if you test and submit a patch to that effect.  I am
> > also open to other suggestions.
> 
> That should not be necessary.  The following patch fixes the build of
> gpgme-1.1.2 on cygwin:
> 
> http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/libs/gpgme/gpgme-1.1.2-1.src.patch
> 
> A similar patch may be necessary for libgpgme_pth_la_LDFLAGS; pth isn't
> part of the distro however, so I haven't tried it.
> 
> (If the above is true, you can just remove the $(no_undefined)
> conditional and use '-no-undefined' throughout.)

Interesting.  Can you explain why this works?

Anyway, I have changed GPGME in SVN HEAD to not use a non-installed
library at all.  This should fix the problem as well.  It would be
good if someone tested out if that is indeed the case.

Thanks,
Marcus