Re: portsupgrade and XFree86-4.4.0

>>>>> "Roman" == Roman Neuhauser <neuhauser_at_chello.cz> writes:

Roman> # sascha_at_daemonground.de / 2004-04-15 09:48:33 +0200:
>> On Thu, 2004-04-15 at 09:28, Peter Weiss, Sun Microsystems, Germany wrote:
>> > relatively new to FreeBSD I'm running a bleeding edge CVS > installation
>> with XFree-4.4.0 binaries installed (damn radeon > support is missing in
>> version 4.3.0) over the existing 4.3.0.
>> 
>> Just use XFree86-4-Server-snap instead of XFree86-4-Server.  My radeon
>> works perfectly well with the snap server port.

Roman>     Alternatively, look for HOLD_PKGS in /usr/local/etc/pkgtools.conf

Roman> [...]

I think I've solved this:

o I deleted all packages depending on X11.
  
o Then a manually compiled XFree-4.4.0 from the sources and installed it.

o I faked the installed XFree-4.3.0 ports to be 4.4.0 (replacing strings in
  /var/db/pkg/XF*/+CONTENTS, plus the one of imake and dri ports). After
  running pkgdb -uF the package database was in consistent state again (at
  least I believe... ;-).

o Now I'm able to portinstall anything and it's being compiled against the 
  correct libs.

Background behind this is:

The libc_r/ libthread nightmare. Some libraries (such as
/usr/X11R6/lib/libGL.so) used to depend on libc_r in the default XFree-4.4.0
distributed precompiled binaries.  After installing some ports binaries were
getting linked against libthread.so. If any binary that uses libthread.so
also uses e.g. libGL.so it could not be started.

After compiling XFree-4.4.0 manually from the sources on FreeBSD-5.2-current
this stuff now uses libthread.so (I had to fix a Makefile entry to enforce
this). So installing ports now does not complain about any conflicting thread
libraries.

Peter

-- 
Peter Weiss               / Peter.Weiss_at_germany.sun.com
Sun Microsystems GmbH     / Sonnenallee 1, D-85551 Kirchheim-Heimstetten
(+49 89) 46008 2947       / mobil 0177/ 60 40 121