[Xlibs] Shared library support on Cygwin

[Harold L Hunt II]

Jim Gettys wrote:

> On Tue, 2004-01-13 at 13:14, Harold L Hunt II wrote:
> 
>>Currently there are two issues with building shared libraries from the 
>>xlibs repository on Cygwin:
>>
>>1) We need to set "LDFLAGS = -no-undefined" for all libraries that do 
>>not export undefined symbols.  There are ways of doing this such that 
>>this flag is only added when compiling on Cygwin.  However, I do not 
>>believe that there is an adverse affect to having the flag present when 
>>not compiling on Cygwin (it should be ignored if shared libs are allowed 
>>to have undefined symbols on the current platform).  Are there any 
>>objections to adding this flag to all libs in the xlibs repository that 
>>do not export undefined symbols?  Also, is there a volunteer that would 
>>like to do this for me?
> 
> 
> What's the existence of this flag on non-gcc compilers?  People
> will certainly want to be able to use them. We certainly need to get
> a wider variety of systems building this stuff to uncover such issues
> more easily.  I'll look into seeing if we have any old Alpha's kicking
> around we could use, as my contribution here, but in general, in
> the long term, I think we need to get a tinderbox set up to make such
> changes much safer/faster/less overhead to make than the endless dialogs
> we'll have on build issues if we have no routine testing.

Oops, I should have been more specific: -no-undefined is a libtool flag, 
not a gcc flag.  For more information, see:

libtool --mode=link --help

"-no-undefined     declare that a library does not refer to external 
symbols"

> If it isn't universal (which I suspect), then provision has to be made
> so that this flag wouldn't get passed to a compiler that doesn't
> understand it.
> 
> So in practice, it will be pragmatism like this that governs any
> objections, as far as I can see.

Well, unless we decide to both use and not use libtool, then it 
shouldn't be a problem ;)

> For those not familiar with it, tinderbox is a continuous build/test
> environment that a number of projects (most notably Mozilla, who
> developed tinderbox) that allows test machines to be anywhere,
> and lets them know quickly if any checkin "breaks the build".

I agree, but I cannot pitch in to set this up.

>>2) This may be related to #1... but Xau is being directly linked when 
>>X11 is linked.  Currently, Xau is built as static (but the question is, 
>>does it have to be static, or does it not export undefined symbols?); on 
>>Cygwin, shared libraries cannot be linked to static libraries, so X11 
>>will be forced to be static only if linked to a static Xau.  I checked 
>>my build logs for the xc-style tree and I do *not* see Xau being linked 
>>to X11.  Is there a reason why Xau is being linked to X11 in the xlibs 
>>tree?  If not, can we remove the -lXau from the X11 link line?
>>
> 
> 
> Possibly/probably we could remove it; it wouldn't be the first time that
> X libraries were linked against libraries unnecessarily.

Keith was right... it is required unless we make copies of some Xau .c 
files.  I just got confused and thought that Xau was the lib that Keith 
had said could never be shared.

Harold