for platforms with shlibs already (and are.)
this obsoletes our hacks for the libgcc specs to use libgcc_pic, and
fixes a couple of other issues reported to me directly.
commands in bsd.clean.mk encounter errors like "exec(/bin/sh)
failed (Argument list too long)". Avoid that by splitting the
files to clean into several lists using different variable names.
This should fix PR 45397, at least until the number of files
grows much larger.
-Wl,-rpath does not expand =, so just drop it.
Drop -Wl,-rpath-link entries that duplicate the -Wl,-rpath entries, this
is done implicitly now that ld is built with sysroot support.
Use ${DESTDIR} explicitly for the remaining -Wl,-rpath-link entries.
the debug symbols and adding the debug-link to .debug.
Use '(rm -f file; false)' in the failure path to force failure.
Based on solution proposed by Nicolas Joly on tech-toolchain in July 2010.
Should fix PR toolchain/44046 from Andreas Gustafsson.
we're ELF now, and there are many missing checks against OBJECT_FMT.
if we ever consider switching, the we can figure out what new ones
we need but for now it's just clutter.
this doesn't remove any of the support for exec_aout or any actually
required-for-boot a.out support, only the ability to build a netbsd
release in a.out format. ie, most of this code has been dead for
over a decade.
i've tested builds on vax, amd64, i386, mac68k, macppc, sparc, atari,
amiga, shark, cats, dreamcast, landisk, mmeye and x68k. this covers
the 5 MACHINE_ARCH's affected, and all the other arch code touched.
it also includes some actual run-time testing of sparc, i386 and
shark, and i performed binary comparison upon amiga and x68k as well.
some minor details relevant:
- move shlib.[ch] from ld.aout_so into ldconfig proper, and cut them
down to only the parts ldconfig needs
- remove various unused source files
- switch amiga bootblocks to using elf2bb.h instead of aout2bb.h
conflicts with shared libaries names libXX.so; as recently seen with
MKUPDATE=yes builds for libelf and libnvpair.
All now stalled regular .so files need to be manually removed from
object directories.
to ${LD} via:
${LDADD.${PROG}}
${LDFLAGS.${PROG}}
${LDSTATIC.${PROG}}
${LDADD.${LIB}}
${LDFLAGS.${LIB}}
OTOH you can't pass parameters to ${CC}, because in suffix rules make(1) only
knows the name of ${.IMPSRC} and ${.TARGET}; it's users' responsivility to
define ${CC} parameters to all the sources of a given ${PROG} / ${LIB}.
Should address bin/42381.
(Bug in this commit log was pointed out by mrg@.)
don't add ${CPPFLAGS_ISYSTEM} or ${CPPFLAGS_ISYSTEMXX} to refer
${DESTDIR}/usr/include or ${DESTDIR}/usr/include/g++.
This change might cause errors on some MD stand dir, but in that case
each Makefile should be fixed to search proper system include paths
by -Ipath option in own CPPFLAGS.
when installing hard links. They have no effect except when using a
metalog, in which case the information is added to the metalog. In
the future, these variables may be replaced by a method for explicitly
recording hard links in a metadata log.
Also change a few things that called ${INSTALL_LINK} without going
through bsd.links.mk.
Reviewed by perry and joerg. This should fix PR 24457 and PR 41155.
is set to "yes" -- defaults to "no" except for build.sh builds. This
results in a deterministic .a file rather than one that reflects
timestamps and permissions on the source files.
Also, clean up the ar flags we're using, and remove a redundant use of
ranlib that on a modern POSIX ar can be done with the "s" flag.
Discussed on tech-toolchain
library. This is mostly a convenience, so that you can trigger
a shared library rebuild by touching the shlib_version file, it
should not otherwise impact the build one way or the other.
shared library. This is done so that -L options pointing into
DESTDIR will come after -L options pointing into our object tree
for shared libraries this shared library depends on.
This makes a difference when shared library major numbers are bumped
(as was recently done in our tree), and you build into an already-
populated DESTDIR, because otherwise the old major version shared
libraries will be picked up, because the new ones have not yet been
installed at this stage. This will in all probability lead to
conflicts later on when linking programs, where one would try to
mix new and old major versions for the same shared library.
I *hope* this will not have any negatively impact by moving other
order-dependent options around; local tests with rebuilds did not
uncover any problems I could see.
OK'ed by lukem@
libraries for space-constraint systems. The description is based on the
feedback of hubertf@, the logic on input from lukem@
This obsoletes the removal of LIBC_SCCS and SYSLIBC_SCCS for libc builds.
