[Xcb] Patches to build X11 w/ XCB on Sol

[Travis Spencer]

On 5/15/05, Jamey Sharp <jamey at minilop.net> wrote:
> On Sat, 2005-05-14 at 23:30 -0700, Travis Spencer wrote:
> > On Sun, Apr 03, 2005 at 12:52:01PM -0700, Jamey Sharp wrote:
> > > If it hangs, we'll have to do something else. You
> > > need to make sure libpthread is linked in or the test won't be valid;
> > > the command I used is:
> > >     gcc -Wall -lX11 -lpthread rec-lock.c -o rec-lock
> >
> > I didn't need libpthread but I needed libnsl and libsocket for some
> > reason.
>
> Um... libpthread needs to be linked in by something, either when
> compiling libX11 or when compiling the test program, or else I wouldn't
> expect the test to be valid. You might want to run `ldd rec-lock` and
> ensure that libpthread appears somewhere in the output.

$ ldd rec-lock
        libX11.so.6 =>   /stash/tspencer/builds/solaris-current/lib/libX11.so.6
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libXCB.so.0 =>
/disk/trump/tspencer/builds/solaris-current/lib/libXCB.so.0
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libXau.so.6 =>
/disk/trump/tspencer/builds/solaris-current/lib/libXau.so.6
        /usr/platform/SUNW,Sun-Blade-1500/lib/libc_psr.so.1

It isn't' in there.  Maybe it is coming from somewhere else.  Does it matter?

> As for libnsl and libsocket, XCB should have been linked against those
> already, so shared library dependencies should have taken care of it.

Any suggestions on determining where the linking problem cropped in?

> Either you're building statically, or XCB's configure script isn't
> working the way I meant it to, or I don't understand something.

I've said in the past that I build things statically, but this isn't
what I actually do.  What I'm doing is recording the search paths of
dynamically loaded libraries in the  object's runpath using the -R
option during compilation.  Later, if LD_LIBRARY_PATH is defined, it
paths will be searched first.  So, my programs are properly linked at
run time even though they are installed in odd places while remaining
flexible enough to later use alternative libraries if need be.

> No, I've reviewed and committed it. Unfortunately I just discovered I
> didn't review it carefully enough (__GLIBC__ isn't defined unless
> features.h is included -- d'oh) so I'll be committing another patch
> shortly to restore glibc support. (I did test your patch before
> committing, but with a threaded app; it doesn't work for non-threaded
> apps on glibc.)

Oops.  Sorry.  I'll be more careful about stuff like that in the
future.  Thanks for bearing with me as I get up to speed :)

--

Regards,

Travis Spencer
Portland, OR USA