[Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Steven B. <sw...@uc...>]

Andreas Rottmann wrote:

> I've switched away from CVS some time ago. The current version of
> libsigcx is in my GNU Arch archive[0]. I should probably wipe out CVS
> and put a pointer to the Arch archive in there.
> 
> [0] http://yi.org/rotty/Software#gnuarch
> 
> FYI, am not *actively* developing libsigcx anymore, but patches are
> always welcome.

No prob., I have some stuff that moves at the speed of patches as well. :)

You already seem to have fixed the libtool.m4 issue in the arch tree, 
and the version of one of the libs changed, so I've updated the patch to 
work against the current arch tree and attached it.  The result builds 
out of the box on Cygwin, Debian Woody, and Debian Sarge, and passes check.

>>ChangeLog from the attached patch:
> 
> [...]
> 
>>	* sigcx/Makefile.am: Add -no-undefined to the LDFLAGS of the
>>	shared libraries as Windows DLLs can't deal with undefined
>>	symbols - sigcx doesn't depend on having them, anyway.
>>
> I'm not sure about this one; I know that -no-undefined is needed for
> MinGW and Cygwin, but do you have any reference that explains why it
> doesn't hurt on other platforms?

As long as the resulting library doesn't require undefined symbols, it's 
not a problem.  -no-undefined basically just asserts that you know your 
code doesn't require that feature (I can't even think of a library that 
does actually require it - maybe ld-linux.so?).  I assume it's only for 
legacy reasons that it's not on by default and there'd be a "-undefined" 
flag instead.  Without it, it would let you successfully build a shared 
lib that the toolchain knew couldn't ever be linked to anything without 
additional help from the user.

Last I remembered, -no-undefined was unfortunately treated as a NOOP on 
Linux which would result in not catching some build errors until you 
tried using the shared lib, but I ran into this while looking:

http://lists.gnu.org/archive/html/libtool-patches/2003-06/msg00023.html

It might have finally made it into libtool in the 1.5 branch.