On Tuesday January 24 2017 22:57:17 Clemens Lang wrote: > > %> strace -o strace.log port -nok destroot foo > > %> strace port -nok destroot foo >& strace.log > > Remember that files that have been present in destroot before might > affect the result, too. Some ports' destroot phases are written in ways > that they cannot be repeated (that doesn't seem to be the case here, but > it's worth keeping it in mind).
Of course. I didn't mention it, but I erased the whole destroot directory before making another attempt. I've a script for that which also "rewinds" the state file. > The only difference in MacPorts behavior I would expect here is the > check whether output is to a terminal. Between the 2 commands above? Indeed, but there must be subtle differences in the overall context. Strace inserts code to replace standard library functions with wrappers that generate trace output, and when that output doesn't go to file directly I'd expect it to end up in main.log (in practice I'm apparently wrong there). > > initialisation, but that shouldn't be possible. Not in install.c in > > any case, but could there be a reason to assume that the argument > > parsing goes wrong somewhere? > > If that's something you suspect, I recommend you compile a copy of > Pextlib with address sanitizer. Since Pextlib is probably dlopen(3)'d by Actually, I wasn't thinking about Pextlib here, because InstallCmd() is apparently called directly from the Tcl interpreter. I could use gcc's sanitiser on Tcl itself, of course. But I had another episode well after I posted my question, which allowed me to run the process through valgrind and got me a bit further after I made the xinstall -v option activate a verbose mode. Apparently the issue is not in Tcl or Pextlib, but in getmode()/setmode(): if and when things go wrong the 775 (sic) mode I'm requesting in the Portfile is translated to a mask of 0255. My distro version had an outdated libbsd; I'm not yet sure if the update I grabbed from a later distro version actually changes anything in the setmode/getmode functions, but at least valgrind no longer complains about using an uninitialised when called from InstallCmd. 0775 (00000001:11111101) turning into 0255 (0000000:10101101), there's no logical explanation (involving umask()) for that, is there? > > Either way, I think that install.c's install_dir() really shouldn't > > ignore chmod() errors silently ... > > Patch to add error checking welcome. I'll post a patch tomorrow. There *is* error checking, btw, there's just no action that's taken when an error does occur. I take it there's less interest in the part that makes the -v option turn on verbose mode? R.
