Port-pmax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: netbsd pmax 4.0/pkgsrc make process - dependencies not automatically building




I've never added any DEPENDS_TARGET line in mk.conf for pkgsrc...and it walways works for me. maybe remove that line and see how 'make' (dont even need the name) works for some random package?

isildur


On Sat, 11 Oct 2008, Ben Hodgens wrote:

Date: Sat, 11 Oct 2008 17:25:24 -0600
From: Ben Hodgens <ben%hodgens.net@localhost>
To: port-pmax%NetBSD.org@localhost
Subject: netbsd pmax 4.0/pkgsrc make process - dependencies not automatically
    building

Hi, hopefully someone here can help me with this. I've exhausted several knowledgeable channels on Freenode already. :)

The situation:

I am trying to build packages on a fresh install of NetBSD on an emulated DECstation 5000/200. After doing a fresh install of NetBSD 4.0 via CD media (all sets except games), I have added one line ("DEPENDS_TARGET=package") to my /etc/mk.conf file, ftp'd down the pkgsrc tree, untarred to /usr/pkgsrc, cd'd into the directory of the package I want to build, and done a 'make package'. Those are the exact (and only) steps I have undertaken. (I have done it twice now from a completely "empty" install - once with "current" and once with "2008Q3" pkgsrc trees). I have also tried this process without the DEPENDS_TARGET entry in my mk.conf.

The problem:

Every time I attempt this, without regard for the package (I've done jed, matchbox-wm, flwm, and several others I can't think of at this hour), make will fail to make the dependencies. The parent/actual item I'm trying to build will error out complaining about dependencies; for instance, flwm will complain about fltk not existing; building fltk will complain about glu; matchbox will complain about libmatchbox not existing. If I go to build libmatchbox, -that- will complain about png not existing - and so on and so forth.

Example:

Here is an example of the tail end of 'make package -dx' within the fltk dir of the pkgsrc tree:

+ /usr/bin/touch -f /usr/pkgsrc/x11/fltk/work/.buildlink/.buildlink_x11-links_done
+ . /etc/shrc
+ set -e
+ true => Linking glu files into /usr/pkgsrc/x11/fltk/work/.buildlink.
+ . /etc/shrc
+ set -e
+ echo ERROR: glu>=3.4.2 glu>=6.0 is not installed; can't buildlink files.
ERROR: glu>=3.4.2 glu>=6.0 is not installed; can't buildlink files.
+ exit 1
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/x11/fltk
+ exitcode=1
+ /usr/bin/env MAKECONF=/etc/mk.conf PATH=/usr/pkgsrc/x11/fltk/work/.wrapper/bin:/usr/pkgsrc/x11/fltk/work/.buildlink/bin:/usr/pkgsrc/x11/fltk/work/.gcc/bin:/usr/pkgsrc/x11/fltk/work/.tools/bin:/usr/pkg/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin /usr/bin/make _MAKE=/usr/bin/make OPSYS=NetBSD OS_VERSION=4.0 LOWER_OPSYS=netbsd _PKGSRCDIR=/usr/pkgsrc PKGTOOLS_VERSION=20081002 PKG_BUILD_OPTIONS.MesaLib= _CC=/usr/bin/cc _PATH_ORIG=/sbin:/usr/sbin:/bin:/usr/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin _PKGSRC_BARRIER=yes barrier-error-check
+ . /etc/shrc
+ set -e
+ /bin/rm -f /usr/pkgsrc/x11/fltk/work/.warning/*.tmp
+ test -d /usr/pkgsrc/x11/fltk/work/.warning
+ cd /usr/pkgsrc/x11/fltk/work/.warning
+ test ./* != ./*
+ exit 0
+ . /etc/shrc
+ set -e
+ /bin/rm -f /usr/pkgsrc/x11/fltk/work/.error/*.tmp
+ test -d /usr/pkgsrc/x11/fltk/work/.error
+ cd /usr/pkgsrc/x11/fltk/work/.error
+ test ./* != ./*
+ exit 0
+ exit 1
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/x11/fltk

Again, I've gotten this for every dependency which hasn't been previously installed manually (eg. 'make package' or 'make install' in, for instance, x11-links - which was also not automatically building, requiring me to build it manually); my understanding is that dependencies are automatically built/installed (and with the mk.conf entry I've got, turned into packages themselves). Is this a correct understanding? Am I doing something wrong, or might I have stumbled

One caveat I will add: I am running this port under the gxemul architecture emulator. It runs stably (more stable than hpcmips on my mobilepro 780, actually) and I've not had any direct noticeable problems aside from this, and the gxemul developer has done what I am trying to do in the past. While I'm not 100% ready to rule out gxemul as the cause of the problems, I strongly suspect it isn't.

I'm new to NetBSD and I'm not sure where to start looking for the problem. Any pointers or suggestions would be greatly assistive!

Thank you,
--

Benjamin Hodgens
ben%hodgens.net@localhost



Home | Main Index | Thread Index | Old Index