[Xlibs] Shared library support on Cygwin
Harold L Hunt II
huntharo@msu.edu
Wed, 14 Jan 2004 00:09:47 -0500
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