Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Dec 2002 11:21:01 +0200
From:      Vladimir Chukharev <chu@gpi.ru>
To:        freebsd-stable@freebsd.org
Subject:   Re: The plot thickens (problem solved!) (was Re: More information ...)
Message-ID:  <3E04327C.D7948A41@gpi.ru>

next in thread | raw e-mail | index | archive | help
I can share my experience with this problem. 

I got the same kind of linking errors for most ports with libXt 
(IIRC, it was libXt, not just libX) after upgrading XFree86* 
via portupgrade with -O3 in my make.conf. 
I had problems with X ports not first time, I remember that 
it is clearly said do not report untill you reproduce it without 
optimization. 
So I tried to remove optimization and started to rebuild 
everything without -O3.

Two previous times I removed /usr/X11R6 and successfully 
reinstalled X and then all needed packages. When I reported 
success in followup to PR, the PR was closed. (Well, I said 
it can be closed, if there is no interest in hunting this bug, 
which hunting is hardly a fun.)

This time I managed to coupe by forced reinstall of 
x11/XFree86-4-libraries, x11-servers/XFree86-Server and
x11/XFree86-4-clients in a particular order. The forced 
reinstall of XFree86 metaport does not help.
I don't remember now the correct order, but first I tried 
two other orders without success. I believe there is a bug 
in mutual dependencies of these ports. It is exposed only 
when updating to incompatible version. 
In this case incompatibility was induced by -O3. 

I don't know if this can be of any help...

Best regards,
V.Chukharev

> > > Later attempts _without_ optimalisations resulted in the same errors. I
> > > did use portupgrade -fR, and I _do_ keep a clean and tidy system. I
> > > cvsup religiously, rebuild world/kernel when needed, and read UPDATING 
> > > etc. etc. There's absolutely no reason why this couldn't have affected 
> > > someone else as well. Even from a clean environment (everything X related 
> > > removed, as in pkg_delete all of X and nuking what's left as in rm -rf
> > > /usr/X11R6) this glitch occured *again*. Odd, no? 
> > >
> > > Oh, I must've recompiled the whole (and parts) of X like 10 times today. I 
> > > also rebuild world and kernel again just to make sure my toolchain and 
> > > evironment was pristine.
> > 
> > OK, that's good to know. I didn't see these facts before in your other mails.
> 
> I might have taken my practice of keeping my system as tidy as possible
> for granted with other setups. I just assumed everyone's system was as
> tidy as mine :)
> 
> [snip]
> 
> > > I might be the first to have noticed. What if suddenly 20 more people in
> > > the span of the next 24 hours report that X or X apps won't build?
> > 
> > That's of course true, but 16 hours have passed since your first email
> > and noone else reports such a problem. Experience has shown that X build
> > problems will probably be reported more frequently here or on -ports
> > during that period if they affect all of the FreeBSD user group.
> > Or maybe everyone's on holiday of course, I don't know...
> 
> Hey, it's not every day one gets to find a bug in Xfree/FreeBSD. I jumped 
> at it. Just doing my bit. Maybe I did overdo it a bit...
> 
> > What I'm trying to say, politely, is something like 'patience, young jedi',
> > I think you will get more results from the lists that way. No offense
> > meant.
> 
> None taken.
> 
> > BTW, I also didn't see a response to Joe Marcus Clarke's questions:
> > 
> > > What ports are broken because of this?  Any port which can't find
> > > -pthread or -lc_r on its own should have ${PTHREAD_LIBS} added to its
> > > LIBS configure argument.  With that, there are also some thread-related
> > > CFLAGS that should be added.  These are defined by the ports system as
> > > ${PTHREAD_CFLAGS}.
> > 
> > Except for your test program, what ports don't work? What lead you to
> > the initial conclusion that something is wrong with X?
> 
> All ports that wanted to link with -lX11 broke here. I suspected that X
> was the problem when I digged through the autoconf config.log files
> which stated everytime that libXThrStubs.so.6 had unresolved symbols, so I
> started grepping for those symbols in the X lib source.
> 
> When I found them, I found a UIThrStubs.c.orig file which meant that
> that file was patched. I put two and two together and looked at what was
> patched, and concluded that that was the source for the unresolved
> symbol problems. When I undid the patch to that file, all was well and 
> linked happily again. Even my test code worked as expected. 
> 
> So there you have it :)
> 
> Cheers,
> Emiel

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E04327C.D7948A41>