tech-pkg archive

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

autoswc and/vs. bmake/make and libtool -- how many developers use autoswc?

So with a pkgsrc version up to about two years ago I was using autoswc
quite successfully, with one caveat.

Autoswc has one _major_ problem, IFF run as root, that I have mostly
fixed for myself some time ago, and finally turned into this patch:

Index: pkgtools/autoswc/files/
RCS file: /cvs/master/m-NetBSD/main/pkgsrc/pkgtools/autoswc/files/,v
retrieving revision 1.3
diff -u -r1.3
--- pkgtools/autoswc/files/	11 Oct 2008 18:03:58 -0000	1.3
+++ pkgtools/autoswc/files/	22 Mar 2022 20:52:42 -0000
@@ -102,6 +102,9 @@
 # The permissions may change during the execution of this script, but this
 # won't bring us problems.  This check is just done to save some time in
 # case we got the wrong user running autoswc.
+if type chflags >/dev/null 2>&1; then
+	chflags nouchg ${confcache}
 touch ${confcache} >/dev/null 2>&1 || err "can't update ${confcache}"

 # Ensure that the source exists.
@@ -154,6 +157,9 @@
 # Update the cache file.  We don't give it write permissions since we don't
 # want third-party configure scripts update it with unwanted results.
 install -c -m 444 config.cache ${confcache} || err "can't update ${confcache}"
+if type chflags >/dev/null 2>&1; then
+	chflags uchg ${confcache}

 cd -

This prevents most packages from butchering the cache file with their
own results, though some, like lang/erlang, still manage to do so
somehow, on at least Darwin.


However in the past weeks I've upgraded (finally) to pkgsrc-current and
I've been plagued by problems related to either libtool and/or not
having been careful enough with my shell environment when running
autoswc (i.e. to generate the system cache file).

The biggest problem has been accidentally using "bmake" when I should be
using "make" on NetBSD (because I have been doing builds on Darwin in
parallel -- maybe I should put /opt/pkg/bin earlier in my path and
hand-make a link from bmake to make there so I don't confuse myself).

Unfortunately "bmake -v CC" gives a different result to "make -v CC" on
NetBSD (by default, "cc" vs. "gcc"), and so I've had the bad luck to
have accidentally used "bmake" to build libtool-base.

Libtool bakes in what it calls the default "tagged configuration" that
it auto-selects when there's no "--tag" option, AND IFF the compiler
being invoked matches the compiler that was found when libtool was
configured and built.

So, if you happen to have built libtool-base with "bmake" by accident,
you end up with this error (e.g. from a "libtool --mode=compile ${CC}"
command, unless the package configure happens to also find "CC=cc"):

	libtool: compile: unable to infer tagged configuration
	libtool:   error: specify a tag with '--tag'

I also messed up once by accidentally running autoswc when I had the
/usr/src $TOOLDIR in my path!  This causes the same problem for packages
using configure scripts that load the autoswc cache file.

I mention all this because it raises some partly intertwined issues I
wanted to discuss:

1. Maybe when "bmake" is installed on NetBSD is should use /usr/share/mk
   instead of the pkgsrc-supplied mk-files (which are currently broken
   for some uses, and bit-rotting by the day, and I for one think they
   should be replaced by Simon's latest mk-files anyway as that would
   solve all of the breakage and bit-rotting and most future maintenance
   issues in one go)

2. Maybe libtool could/should be patched so that it considers all of the
   allowable/supported pkgsrc compilers as recognized compilers?

3. Maybe autoswc shouldn't have any AC_PROG_* macros?  I.e. it shouldn't
   cache the values of any toolchain programs, especially not CC/CPP/CXX

					Greg A. Woods <>

Kelowna, BC     +1 250 762-7675           RoboHack <>
Planix, Inc. <>     Avoncote Farms <>

Attachment: pgpsYzB1GcUaA.pgp
Description: OpenPGP Digital Signature

Home | Main Index | Thread Index | Old Index