base: parallel build broken

[ryandesign (Ryan Carsten Schmidt)]

I can't build MacPorts trunk @54097 on Mac OS X 10.4.11 Intel

===> making install in src/programs
===> making install in src/programs/daemondo
/usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /macportstest/bin
[ ! -f /macportstest/etc/macports/mp_version ] || rm -vf /macportstest/etc/macports/mp_version
/usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash  /macportstest/share/macports/
/usr/bin/tclsh src/upgrade_sources_conf_default.tcl /macportstest
/usr/bin/tclsh src/dep_map_clean.tcl /macportstest/Library/Tcl
invalid command name "get_systemconfiguration_proxies"
    while executing
"get_systemconfiguration_proxies"
    (procedure "mportinit" line 440)
    invoked from within
"mportinit"
    (file "src/dep_map_clean.tcl" line 12)
make: *** [install] Error 1

[blb@…]

Did you distclean in the tree prior to configuring and building? I recently moved the proxy stuff from Pextlib to macports1.0 in r53743.

[ryandesign (Ryan Carsten Schmidt)]

Replying to blb@…:

Did you distclean in the tree prior to configuring and building?

I have not been; I have been using make clean. But I used make distclean now, and removed all remaining ignored files, and still get the same error at make install time.

[tobypeterson]

Does 'svn st --no-ignore' show anything in base?

[blb@…]

Weird, it works fine when I try to a directory owned by me, though it is a different path than what you are using. Considering

/usr/bin/tclsh src/dep_map_clean.tcl /macportstest/Library/Tcl

it is happening when the mportinit is run, which should be coming from the just-installed macports1.0 code in /macportstest/Library/Tcl; is the file /macportstest/Library/Tcl/macports1.0/MacPorts.dylib updated with the right timestamp?

[ryandesign (Ryan Carsten Schmidt)]

Replying to toby@…:

Does 'svn st --no-ignore' show anything in base?

It did show one Makefile but I removed it already ("removed all remaining ignored files").

Replying to blb@…:

Weird, it works fine when I try to a directory owned by me, though it is a different path than what you are using. Considering /usr/bin/tclsh src/dep_map_clean.tcl /macportstest/Library/Tcl it is happening when the mportinit is run, which should be coming from the just-installed macports1.0 code in /macportstest/Library/Tcl; is the file /macportstest/Library/Tcl/macports1.0/MacPorts.dylib updated with the right timestamp?

/macportstest does not exist before I run the build. After the error occurs, /macportstest/Library/Tcl/macports1.0/MacPorts.dylib does exist and has a current modification timestamp.

I will attach the complete output in case it helps.

[ryandesign (Ryan Carsten Schmidt)]

I was using "make -j3". It looks like the problem goes away if I just use "make". So it's a parallel build issue.

[jmroot (Joshua Root)]

Do we know whether this is a regression? I can't reproduce BTW. But I guess we just need to wait for the subdir install targets to complete before running the top-level one.

[blb@…]

I was able to reproduce this earlier, though now I'm hitting a different error (make sure you use a ${prefix} that doesn't currently have MacPorts installed):

$ ./configure --various-options
...
$ make -j3 install
...
cc -dynamiclib  Pextlib.o strsed.o fgetln.o md5cmd.o setmode.o xinstall.o fs-traverse.o strcasecmp.o vercomp.o filemap.o sha1cmd.o curl.o rmd160cmd.o readline.o uid.o tracelib.o tty.o sysctl.o readdir.o pipe.o flock.o system.o -o Pextlib.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4   -lcurl -lssl -lcrypto -lz -lcrypto -lreadline
/usr/bin/install -c -d -o blb -g blb -m 0755 /Users/blb/MacPorts/mp-test2/share/macports/Tcl/pextlib1.0
/usr/bin/install -c -o blb -g blb -m 444 Pextlib.dylib /Users/blb/MacPorts/mp-test2/share/macports/Tcl/pextlib1.0
/usr/bin/install -c -o blb -g blb -m 444 pkgIndex.tcl /Users/blb/MacPorts/mp-test2/share/macports/Tcl/pextlib1.0
install: pkgIndex.tcl: No such file or directory

Running again gets further, but still errors...

I tried adding .NOTPARALLEL but I just noticed there are other issues as well. If you go straight from configure to {{{make install}} it still fails.

[tobypeterson]

should be fixed in #54781

[tobypeterson]

Er, r54781