NetBSD Problem Report #43550

From www@NetBSD.org  Fri Jul  2 05:26:55 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id ACBAC63BA6C
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  2 Jul 2010 05:26:55 +0000 (UTC)
Message-Id: <20100702052655.77C3B63BA69@www.NetBSD.org>
Date: Fri,  2 Jul 2010 05:26:55 +0000 (UTC)
From: jdbaker@mylinuxisp.com
Reply-To: jdbaker@mylinuxisp.com
To: gnats-bugs@NetBSD.org
Subject: x11/Xfixes configure fails on MacOS X 10.4.11 (PPC)
X-Send-Pr-Version: www-1.0


>Number:         43550
>Category:       pkg
>Synopsis:       x11/Xfixes configure fails on MacOS X 10.4.11 (PPC)
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 02 05:30:00 +0000 2010
>Closed-Date:    Fri Feb 01 22:48:24 +0000 2013
>Last-Modified:  Fri Feb 01 22:48:24 +0000 2013
>Originator:     John D. Baker
>Release:        MacOS X 10.4.11 PPC ; pkgsrc-current (pre-2010Q2)
>Organization:
>Environment:
Darwin ed.technoskunk.fur 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc


>Description:
Building x11/Xfixes (a dependency of xcursor, qt3-libs, and ultimately
mplayer) fails during configuration with:


[...]
checking for XTHREADS in Xlib... yes
checking for fixesext >= 2.0... Package 'FixesProto' requires 'xextproto >= 7.0.99.1' but version of XExtensions is 1.0.1
configure: error: Library requirements (fixesext >= 2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
*** Error code 1


Stop.
bmake: stopped in /usr/pkgsrc/x11/Xfixes
WARNING: *** Please consider adding c++ to USE_LANGUAGES in the package Makefile.
WARNING: *** Please consider adding fortran to USE_LANGUAGES in the package Makefile.
*** Error code 1


Stop.
bmake: stopped in /usr/pkgsrc/x11/Xfixes
[..]
>How-To-Repeat:
On MacOS X 10.4.11 PPC (intel?) attempt to build x11/Xfixes or any
package that pulls it in as a dependency.
>Fix:
Don't know.  I see other Xfixes and "fixesext" PRs, mostly on Solaris.
pkg/39115 seems to be in the same ballpark though.


>Release-Note:


>Audit-Trail:
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550: x11/Xfixes configure fails on MacOS X 10.4.11 (PPC)
Date: Sat, 3 Jul 2010 20:25:23 +0000


 On Fri, Jul 02, 2010 at 05:30:01AM +0000, jdbaker@mylinuxisp.com wrote:
  > Building x11/Xfixes (a dependency of xcursor, qt3-libs, and ultimately
  > mplayer) fails during configuration with:
  > 
  > [...]
  > checking for XTHREADS in Xlib... yes
  > checking for fixesext >= 2.0... Package 'FixesProto' requires 'xextproto >= 7.0.99.1' but version of XExtensions is 1.0.1
  > configure: error: Library requirements (fixesext >= 2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
  > *** Error code 1

 
 My guess is that 10.4 is old enough that stuff like this just isn't
 going to work with native X and you may want to just switch to pkgsrc
 X. :-/

 
 -- 
 David A. Holland
 dholland@netbsd.org

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550: x11/Xfixes configure fails on MacOS X 10.4.11 (PPC)
Date: Mon, 5 Jul 2010 21:40:44 -0500 (CDT)


 On Sat, 3 Jul 2010, David Holland wrote:

 
 > My guess is that 10.4 is old enough that stuff like this just isn't
 > going to work with native X and you may want to just switch to pkgsrc
 > X. :-/

 
 This is an interesting prospect.  I've pondered this myself, but only
 recently have come into a spare machine with which to experiement on a
 major subsystem like this.

 
 I wonder if anyone else has built modular-xorg-*, etc. for MacOS X?  I
 did build X(Free86) 4.4 on 10.1.5 a long time ago and it mostly worked.

 

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550: x11/Xfixes configure fails on MacOS X 10.4.11 (PPC)
Date: Wed, 7 Jul 2010 04:42:23 +0000


 On Tue, Jul 06, 2010 at 03:50:05AM +0000, John D. Baker wrote:
  >> My guess is that 10.4 is old enough that stuff like this just isn't
  >> going to work with native X and you may want to just switch to pkgsrc
  >> X. :-/
  >  
  >  This is an interesting prospect.  I've pondered this myself, but only
  >  recently have come into a spare machine with which to experiement on a
  >  major subsystem like this.
  >  
  >  I wonder if anyone else has built modular-xorg-*, etc. for MacOS X?  I
  >  did build X(Free86) 4.4 on 10.1.5 a long time ago and it mostly worked.

 
 I certainly haven't, but I'd expect at least the client libraries and
 most applications to build and work ok (modulo the usual portability
 issues with MacOS) -- the server might or might not, though.

 
 -- 
 David A. Holland
 dholland@netbsd.org

 
Responsible-Changed-From-To: pkg-manager->tnn
Responsible-Changed-By: tnn@NetBSD.org
Responsible-Changed-When: Fri, 23 Jul 2010 16:14:02 +0000
Responsible-Changed-Why:
There were reports on IRC that this is a problem on NetBSD 4.x
as well, and I sort of promised to take a look at how
we can fix it...




From: Chuck Zmudzinski <brchuckz@netscape.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Sun, 25 Jul 2010 14:56:20 -0500


   I am seeing the same error in configure on NetBSD-4/i386  using pkgsrc 
 as of July 16, 2010 or so, with the XFree86 version of X, but I got 
 Xfixes to configure, build, and install by adding the line

 
 PREFER_PKGSRC=    xextproto

 
 to my /etc/mk.conf.  When reading the pkgsrc guide, PREFER_PKGSRC is 
 supposed to be the default, so I don't understand why I had to 
 explicitly add it for xextproto. Perhaps a bug in the x11 buildlink3 files?

 
From: "Rev. Charles Zmudzinski, C.P.M." <frchuck@fathersofmercy.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Sun, 25 Jul 2010 14:59:56 -0500


   I forgot to mention that in addition to editing my /etc/mk.conf, I had 
 to run 'make clean' in the x11/Xfixes directory before attempting to 
 build and install Xfixes

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: tnn@NetBSD.org
Subject: Re: pkg/43550
Date: Sun, 25 Jul 2010 20:33:16 -0500 (CDT)


 On Sun, 25 Jul 2010, Chuck Zmudzinski wrote:

 
 > PREFER_PKGSRC=    xextproto
 >
 > to my /etc/mk.conf.  When reading the pkgsrc guide, PREFER_PKGSRC is

 
 I've now done this (on MacOS X 10.4.11).  I went to the top-level package
 I was trying to build (mplayer) and while it caused xextproto-7.1.1nb1
 (pkgsrc-current) to be installed, it skipped trying to build/install
 x11/Xfixes (2.0.1nb4) entirely.  A subsequent dependency (qt-libs-3.3.8)
 then failed because Xfixes wasn't installed.

 
 With the above modification to "/usr/pkg/etc/mk.conf", Xfixes was not
 listed among the dependencies prior to building qt3-libs.  A 'bmake
 clean clean-depends' showed it cleaning for Xfixes-2.0.1nb4, however.

 
 Installing x11/Xfixes by hand succeeded and qt3-libs is building.

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Tue, 27 Jul 2010 02:57:39 -0500 (CDT)


 The same happens with "xcursor" and "Xrandr" as well.  Shows up as a dependency
 during "bmake clean-depends", but does not get built automatically.

 
 x11/xcursor installed OK by hand.  I can't seem to figure out Xrandr.
 x11/xrandr seems to start a circular dependency on itself.

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Sat, 31 Jul 2010 19:17:03 +0000


 On Tue, Jul 27, 2010 at 08:00:14AM +0000, John D. Baker wrote:

 
  > The same happens with "xcursor" and "Xrandr" as well.  Shows up as
  > a dependency during "bmake clean-depends", but does not get built
  > automatically.
  >  
  > x11/xcursor installed OK by hand.  I can't seem to figure out Xrandr.
  > x11/xrandr seems to start a circular dependency on itself.

 
 sigh, the wonders of x11-links.

 
 I don't really have any useful suggestions, but there's some small
 chance that recompiling x11-links (particularly if you haven't since
 it was last changed) might help.

 
 -- 
 David A. Holland
 dholland@netbsd.org

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Mon, 11 Oct 2010 19:11:34 -0500 (CDT)


 On 10 October 2010, I cleaned out all packages and rebootstrapped a
 pkgsrc-current.  Following an earlier suggestion in this PR, I added:

 
    X11_TYPE=modular

 
 to "/usr/pkg/etc/mk.conf" before building any further packages.

 
 My first target is usually "x11/rxvt-unicode".  It began pulling in
 bits and pieces (mostly XXXXproto packages, but also both python as
 well as perl).

 
 Then it got to "graphics/freetype2" where it died with:

 
 [...]
 libtool  --mode=compile gcc -pedantic -ansi -no-cpp-precomp -isystem /usr/include -I/usr/include -I/d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs -I./builds/unix -I/d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/include -c -Wall -pipe -O2 -fno-strict-aliasing -I/usr/include -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON -DFT_CONFIG_CONFIG_H="<ftconfig.h>" -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="<ftmodule.h>"  -o /d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs/ftsystem.lo builds/unix/ftsystem.c
 libtool: compile:  gcc -pedantic -ansi -no-cpp-precomp -isystem /usr/include -I./builds/unix -c -Wall -pipe -O2 -fno-strict-aliasing -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" builds/unix/ftsystem.c  -fno-common -DPIC -o /d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs/.libs/ftsystem.o
 builds/unix/ftsystem.c:19:22: error: ft2build.h: No such file or directory
 In file included from builds/unix/ftsystem.c:21:
 ./builds/unix/ftconfig.h:42:10: error: #include expects "FILENAME" or <FILENAME>
 ./builds/unix/ftconfig.h:43:10: error: #include expects "FILENAME" or <FILENAME>
 ./builds/unix/ftconfig.h:103:2: error: #error "Unsupported size of `int' type!"
 ./builds/unix/ftconfig.h:115:2: error: #error "Unsupported size of `long' type!"
 [...]

 
 From where should "ft2build.h" come?

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Tue, 12 Oct 2010 03:20:38 +0000


 On Tue, Oct 12, 2010 at 12:15:04AM +0000, John D. Baker wrote:
  >  libtool: compile:  gcc -pedantic -ansi -no-cpp-precomp -isystem /usr/include -I./builds/unix -c -Wall -pipe -O2 -fno-strict-aliasing -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" builds/unix/ftsystem.c  -fno-common -DPIC -o /d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs/.libs/ftsystem.o
  >  builds/unix/ftsystem.c:19:22: error: ft2build.h: No such file or directory
  > [...]
  >  
  >  From where should "ft2build.h" come?

 
 It's part of the freetype2 distribution, and as far as I can tell from
 ktracing a build on netbsd, the build uses it only out of the build
 tree. (And not, for example, by reading a copy from a previous build
 out of /usr/pkg/include.)

 
 There appear to be two copies in the distribution but the extra one
 seems to be for maintainer-mode only.

 
 -- 
 David A. Holland
 dholland@netbsd.org

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: David Holland <dholland-pbugs@NetBSD.org>
Subject: Re: pkg/43550
Date: Tue, 12 Oct 2010 09:40:13 -0500 (CDT)


 On Tue, 12 Oct 2010, David Holland wrote:

 
 > On Tue, Oct 12, 2010 at 12:15:04AM +0000, John D. Baker wrote:
 >  >  From where should "ft2build.h" come?
 >
 > It's part of the freetype2 distribution, and as far as I can tell from
 > ktracing a build on netbsd, the build uses it only out of the build
 > tree. (And not, for example, by reading a copy from a previous build
 > out of /usr/pkg/include.)

 
 Looking back at the libtool commands and output, it appears that the
 include-dir directive:

 
    -I${WRKOBJDIR}/graphics/freetype2/work/freetype-2.4.2/include

 
 (where ft2build.h resides) was in the original

 
    libtool --mode=compile ...

 
 command, but was omitted when libtool actually ran the compiler.

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Tue, 12 Oct 2010 18:08:42 +0200


 On Tue, Oct 12, 2010 at 02:45:02PM +0000, John D. Baker wrote:
 >  Looking back at the libtool commands and output, it appears that the
 >  include-dir directive:
 >  
 >     -I${WRKOBJDIR}/graphics/freetype2/work/freetype-2.4.2/include
 >  
 >  (where ft2build.h resides) was in the original
 >  
 >     libtool --mode=compile ...
 >  
 >  command, but was omitted when libtool actually ran the compiler.

 
 Does any part of WRKOBJDIR involve symlinks? That can often result in
 such behavior.

 
 Joerg

 
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Tue, 12 Oct 2010 20:03:46 +0000


 On Tue, Oct 12, 2010 at 02:45:02PM +0000, John D. Baker wrote:
  >  Looking back at the libtool commands and output, it appears that the
  >  include-dir directive:
  >  
  >     -I${WRKOBJDIR}/graphics/freetype2/work/freetype-2.4.2/include
  >  
  >  (where ft2build.h resides) was in the original
  >  
  >     libtool --mode=compile ...
  >  
  >  command, but was omitted when libtool actually ran the compiler.

 
 Was it dropped by libtool or by the pkgsrc wrappers? Check work/.work.log.

 
 -- 
 David A. Holland
 dholland@netbsd.org

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: David Holland <dholland-pbugs@NetBSD.org>,
        Joerg Sonnenberger <joerg@britannica.bec.de>
Subject: Re: pkg/43550
Date: Tue, 12 Oct 2010 19:28:07 -0500 (CDT)


 On Tue, 12 Oct 2010, David Holland wrote:
 > On Tue, Oct 12, 2010 at 02:45:02PM +0000, John D. Baker wrote:
 >  >  Looking back at the libtool commands and output, it appears that the
 >  >  include-dir directive:
 >  >     -I${WRKOBJDIR}/graphics/freetype2/work/freetype-2.4.2/include
 >  >  (where ft2build.h resides) was in the original
 >  >     libtool --mode=compile ...
 >  >  command, but was omitted when libtool actually ran the compiler.
 >
 > Was it dropped by libtool or by the pkgsrc wrappers? Check work/.work.log.

 
 I'm not sure how to interpret the entries in this file (and the pkgsrc
 guide doesn't describe them.  At the end of the file are these entries:

 
 [...]
 [*] /d0/tmp/pkgsrc//graphics/freetype2/work/.tools/bin/echo done.
 <.> echo  done.
 [*] /d0/tmp/pkgsrc//graphics/freetype2/work/.wrapper/bin/libtool /d0/tmp/pkgsrc/
 /graphics/freetype2/work/.wrapper/bin/libtool --mode=compile gcc -pedantic -ansi
   -no-cpp-precomp -isystem /usr/include -I/usr/include -I/d0/tmp/pkgsrc/graphics/
 freetype2/work/freetype-2.4.2/objs -I./builds/unix -I/d0/tmp/pkgsrc/graphics/fre
 etype2/work/freetype-2.4.2/include -c -Wall -pipe -O2 -fno-strict-aliasing -I/us
 r/include -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_
 H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" -o /d0/
 tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs/ftsystem.lo builds/unix/f
 tsystem.c
 <.> /usr/pkg/bin/libtool --mode=compile gcc -pedantic -ansi -no-cpp-precomp -isy
 stem /usr/include -I./builds/unix -c -Wall -pipe -O2 -fno-strict-aliasing -DFT_C
 ONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" 
 -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" -o /d0/tmp/pkgsrc/graph
 ics/freetype2/work/freetype-2.4.2/objs/ftsystem.lo builds/unix/ftsystem.c 
 [*] /d0/tmp/pkgsrc//graphics/freetype2/work/.tools/bin/mkdir /d0/tmp/pkgsrc/grap
 hics/freetype2/work/freetype-2.4.2/objs/.libs
 <.> /bin/mkdir -p /d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs/.li
 bs
 [*] /d0/tmp/pkgsrc//graphics/freetype2/work/.wrapper/bin/gcc /d0/tmp/pkgsrc//gra
 phics/freetype2/work/.wrapper/bin/gcc -pedantic -ansi -no-cpp-precomp -isystem /
 usr/include -I./builds/unix -c -Wall -pipe -O2 -fno-strict-aliasing -DFT_CONFIG_
 OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -DFT2_
 BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" builds/unix/ftsystem.c -fno-c
 ommon -DPIC -o /d0/tmp/pkgsrc/graphics/freetype2/work/freetype-2.4.2/objs/.libs/
 ftsystem.o
 WARNING: [transform-gcc] passing unknown option -ansi
 WARNING: [transform-gcc] passing unknown option -no-cpp-precomp
 WARNING: [transform-gcc] passing unknown option -isystem
 <.> /d0/tmp/pkgsrc//graphics/freetype2/work/.gcc/bin/gcc -pedantic -ansi -no-cpp
 -precomp -isystem /usr/include -I./builds/unix -c -Wall -pipe -O2 -fno-strict-al
 iasing -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<
 ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" builds/uni
 x/ftsystem.c -fno-common -DPIC -o /d0/tmp/pkgsrc/graphics/freetype2/work/freetyp
 e-2.4.2/objs/.libs/ftsystem.o -I/d0/tmp/pkgsrc//graphics/freetype2/work/.buildli
 nk/include -L/d0/tmp/pkgsrc//graphics/freetype2/work/.buildlink/lib 
 [EOF]

 
 If I guess correctly, the wrappers are losing the path to the extra
 include directory.

 
 Also:

 
 Joerg Sonnenberger <joerg@britannica.bec.de> wrote:

 
 > Does any part of WRKOBJDIR involve symlinks? That can often result in
 > such behavior.

 
 Yes.  In my /usr/pkg/etc/mk.conf file I have:

 
    WRKOBJDIR=		/d0/tmp/pkgsrc/

 
 where "/d0" is a symbolic link to "Volumes/d0"

 
 I'll try an absolute path without symlinks and see if it changes.

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc: David Holland <dholland-pbugs@NetBSD.org>,
        Joerg Sonnenberger <joerg@britannica.bec.de>
Subject: Re: pkg/43550
Date: Tue, 12 Oct 2010 19:46:02 -0500 (CDT)


 On Tue, 12 Oct 2010, John D. Baker wrote:
 > Yes.  In my /usr/pkg/etc/mk.conf file I have:
 >
 >  WRKOBJDIR=		/d0/tmp/pkgsrc/
 >
 > where "/d0" is a symbolic link to "Volumes/d0"
 |                                   ^^

 
 Because my symlink was relative, it failed.  I re-linked "/d0" to an
 absolute path of "/Volumes/d0" and it built and installed just fine.

 
 Now I wonder how many of my other problems with pkgsrc on MacOS X might
 have been caused by the same thing...

 
 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

 
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Wed, 13 Oct 2010 08:45:04 +0000


 On Wed, Oct 13, 2010 at 12:50:04AM +0000, John D. Baker wrote:
  >  Because my symlink was relative, it failed.  I re-linked "/d0" to an
  >  absolute path of "/Volumes/d0" and it built and installed just fine.

 
 That seems odd. The usual problem with symlinks is that the wrappers
 rely on textual equality of pathnames and build systems that do things
 like "cd $FOO && pwd" end up using different paths that don't match.
 AIUI, anyway.

 
 But absolute vs. relative symlinks should be invisible... although
 maybe MacOS is doing something weird and/or something is tripping on
 the weird ksh symlink-crossing behavior.

 
  >  Now I wonder how many of my other problems with pkgsrc on MacOS X might
  >  have been caused by the same thing...

 
 Quite a few, I bet. When the wrappers go kablooey everything fails in
 really strange ways.

 
 -- 
 David A. Holland
 dholland@netbsd.org

 
From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/43550
Date: Wed, 13 Oct 2010 13:29:29 +0200


 On Wed, Oct 13, 2010 at 12:50:04AM +0000, John D. Baker wrote:
 > The following reply was made to PR pkg/43550; it has been noted by GNATS.
 > 
 > From: "John D. Baker" <jdbaker@mylinuxisp.com>
 > To: gnats-bugs@NetBSD.org
 > Cc: David Holland <dholland-pbugs@NetBSD.org>,
 >         Joerg Sonnenberger <joerg@britannica.bec.de>
 > Subject: Re: pkg/43550
 > Date: Tue, 12 Oct 2010 19:46:02 -0500 (CDT)
 > 
 >  On Tue, 12 Oct 2010, John D. Baker wrote:
 >  > Yes.  In my /usr/pkg/etc/mk.conf file I have:
 >  >
 >  >  WRKOBJDIR=		/d0/tmp/pkgsrc/
 >  >
 >  > where "/d0" is a symbolic link to "Volumes/d0"
 >  |                                   ^^
 >  
 >  Because my symlink was relative, it failed.  I re-linked "/d0" to an
 >  absolute path of "/Volumes/d0" and it built and installed just fine.
 >  
 >  Now I wonder how many of my other problems with pkgsrc on MacOS X might
 >  have been caused by the same thing...

 
 Don't use symlinks for components of WRKOBJDIR at all. Really, point it
 to the resolved location, e.g. the output of
 	cd /d0/tmp/pkgsrc && pwd -P

 
 Anything else is just waiting for breakage.

 
 Joerg

 
Responsible-Changed-From-To: tnn->pkg-manager
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Fri, 01 Feb 2013 22:48:24 +0000
Responsible-Changed-Why:
Back to role account.




State-Changed-From-To: open->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Fri, 01 Feb 2013 22:48:24 +0000
State-Changed-Why:
OS X 10.4 is not supported any longer, sorry.




>Unformatted:

 

Home	PR Database Search