Compiling Python on NetBSD

[Ty Sarna]

In article <895tkq$fr2$1 at news.tht.net>, D'Arcy J.M. Cain <darcy at vex.net> wrote:
> Can someone tell me why the decision was made to use cc on ELF systems
> and ld on a.out?  I checked and my a.out system accepts cc -shared just
> fine.  The reason for asking is that our package building system now

My memory of this is a bit fuzzy now, but I believe it's because "cc
-shared" didn't work on older systems.  At one time, the ELF and a.out
toolchains were fairly different, and I think our system makefiles used
cc on ELF and ld on a.out, and I propagated that. Nowadays the toolchain
is more consistent between the two.

> has to do the same test on every Python package to decide whether to
> add -Wl, in front of the ld flags if there are additional libraries
> to link in.  It would be a lot cleaner if we didn't have to add this
> test in on every package.

No, that's not true. For packages, you can just use -R, since that
works with both cc and ld. This won't work on 1.3.x and earlier, but
anyone using modern pkgsrc on OS versions that old will probably have
other problems anyway -- it's only marginally supported.

> Anyway, I am thinking of patching the configure script in our package
> system so that the NetBSD* simply sets LDSHARED to "cc -shared" in every
> case.  Anyone see a downside to that?

It doesn't buy anything, and creates an unneeded difference between the
package and the standard distribution.  Merging it back into standard
python would be bad, too.  AFAIK, stock Python builds on NetBSD systems
back to 1.0 or so (not that I've tried it lately, but I made some effort
at the time...).