On Sun, 9 Dec 2007 15:26:16 +0000 (UTC), Michel Talon wrote:
: Howard Goldstein wrote:
: >
: > Your ldd dump shows my point exactly, and it should be reassuring to
: > those who are concerned about having old libraries around: The app and
: > lib images know which versions of other libraries they need. Their
: > mere presence is not problematic in and of itself.
: >
:
: No it doesn't show your point. It shows that the same binary can turn
: out linked with two different *versions* of the *same* library. This
: happened to several people who have reported it on the mailing lists.
: In this case, when you call functions in this library, how do you know
: what bit of code will be executed? If you call pthread_mutex_init(), how
: do you know it will refer to one or the other? And maybe the two
: libraries need different initializations, hence a crash.

I think I figured out what's going on here in this really twisted
continuation of the thread. Let me see if I'm right. If you rebuilt
every port on the system but had the old libraries sitting around,
would the situation you describe in the quoted bits above occur?

Howard Goldstein wrote:
>
> I think I figured out what's going on here in this really twisted
> continuation of the thread. Let me see if I'm right. If you rebuilt
> every port on the system but had the old libraries sitting around,
> would the situation you describe in the quoted bits above occur?
>

I don't think so. In the article by D. Eischen i have read recently, he
said to rebuild everything to avoid this effect. I don't think that
having old libraries in "compat" causes problems (of course old headers
may cause problems when you compile). The problem, according to what i
have read comes with the complicated setup i have explained, with
several chains of dependencies closing to a single library. If one of
the chains is upgraded through a partial upgrading, you will get two
copies of a library which should be included once. This has nothing to
do with symlinks or other trivial stuff.


>

--

Michel TALON

On Sun, 9 Dec 2007 16:54:49 +0000 (UTC), Michel Talon wrote:
: Howard Goldstein wrote:
: >
: > I think I figured out what's going on here in this really twisted
: > continuation of the thread. Let me see if I'm right. If you rebuilt
: > every port on the system but had the old libraries sitting around,
: > would the situation you describe in the quoted bits above occur?
: >
:
: I don't think so. In the article by D. Eischen i have read recently, he
: said to rebuild everything to avoid this effect. I don't think that
: having old libraries in "compat" causes problems (of course old headers
: may cause problems when you compile).

Old headers, yes, that's a good point. Regarding having the old
libraries around supposedly breaking new compiles, that's where this
branch of the thread lives. The rest has been for naught.

: The problem, according to what i
: have read comes with the complicated setup i have explained, with
: several chains of dependencies closing to a single library. If one of
: the chains is upgraded through a partial upgrading, you will get two
: copies of a library which should be included once. This has nothing to
: do with symlinks or other trivial stuff.

Are you a native English speaker?

Howard Goldstein wrote:
> Are you a native English speaker?

Of course not.

--

Michel TALON

On Sun, 09 Dec 2007 13:37:46 +0000, Howard Goldstein wrote:

> On 9 Dec 2007 07:41:30 GMT, Andrew Reilly
> wrote:
> : On Sat, 08 Dec 2007 22:54:59 +0000, Howard Goldstein wrote: :
> : > I don't think that can happen without some exceptional forcing.
> When a : > base library version changes the symlinks go with it.
> Subsequent port : > builds are branded with whatever's pointed to at
> buildtime by the : > symlink.
> :
> : (a) the symlink upgrade doesn't protect you from -pthread switch
> bringing : in libpth.so where it used to (on 6.x) bring in
> libpthread.so: different : name.
>
> Did you make delete-old-libs?

I did, eventually, as a way to make all of the doubly-linked applications
break on startup, and produce obvious error messages when ldd was pointed
at them. Initially, no, all of the old libraries were still there, and
many applications would break inscrutably, or dump core.

It's not all that surprising an event. GNOME stuff has shared library
dependency chains ten or more deep, some of which are quite stable, and
so unlikely to be rebuilt by portupgrade unless -af is used. From
memory, one of the main culprits was the GNOME bonobo server (which
hand't been upgraded until I did it manually.) The big gotcha, and
seemingly a flaw in the system, is that portupgrade doesn't track things
like the system C complier linking in a different library when given the -
pthread switch.

Cheers,

--
Andrew

Andrew Reilly wrote:
> hand't been upgraded until I did it manually.) The big gotcha, and
> seemingly a flaw in the system, is that portupgrade doesn't track things
> like the system C complier linking in a different library when given the -
> pthread switch.

Portupgrade cannot track such stuff. The only knowledge it has about
ports, is their version numbers, and the dependencies explicitely (or
implicitely through system make files) mentioned in the Makefile.
In particular it has zero knowledge of things moving in the base system.
This is not really a bug of portupgrade, it depends entirely on the
organization of FreeBSD base and ports system.

>
> Cheers,
>

--

Michel TALON