Use relative symlinks for /usr/lib/libfoo.so -> /lib/libfoo.so.M.N
This should work now that "install -l r -d destdir" works if destdir
contains a symlink.
libname path-to-srcdir-of-libname
For each tuple;
* LIBDO.libname contains the .OBJDIR of the library `libname', and
if it is not set it is determined from the srcdir and added to
MAKEOVERRIDES (the latter is to allow for build time optimization).
* LDADD gets -L${LIBDO.libname} -llibname added.
* DPADD gets ${LIBDO.libname}/liblibname.so added.
library objects, rather than using OBJS to refer to them. This gives us
a separate variable to refer to static library objects that does not affect
profile library objects (which has POBJS) or shared library objects (which
has SOBJS).
and don't install the (.a) library.
This is useful for "build only" helper libraries.
* Add some #{ [...] #} comments around large conditional statements.
- support ${COPTS.<fn>} ${CPUFLAGS.<fn>} ${CPPFLAGS.<fn>}
(deficiency noted by Tyler Retzlaff <rtr@NetBSD.org>)
- use ${COMPILE.s} for .s.o .s.po .s.so (instead of ${COMPILE.S})
- don't support AINC anymore; append to AFLAGS instead
Remove .c.ln - it was a duplicate of the rule in <bsd.sys.mk>
and exception handling have a chance of working properly.
- creates libgcc, libgcc_eh and libgcc_s
- updates LIBGCC_SPEC to use them appropriately.
There's a hack in here at the moment with respect to libgcc_so in that it
is preferable to link against libgcc_so will only when -shared-libgcc is
specified (the c++ frontend does this automatically.) Configurations where
LINK_EH_SPEC is defined already do this. The gcc configuration for
NetBSD/alpha and another NetBSD platform (I forget which) actually define
LINK_EH_SPEC probably by accident rather than design.
- updates share/mk to use the compiler's knowledge of what needs linking into
libraries and executables. This removes an hppa hack.
- updates the sets for the newly created libgcc* files.
- support for linking against the _pg version of libgcc has been removed.
This simplifies using ld with ${DESTDIR}/usr/lib whilst retaining the
(slightly faster) absolute links for the run-time libraries.
Per discussion on tech-toolchain.
(Side note; install(1) -l r needs the source to be prefixed with ${DESTDIR}
to operate correctly, which makes it non trivial to enable '-l r' by default
for all ${INSTALL_SYMLINK}s)
:M-[IDU]*
with
:C/-([IDU])[ ]*/-\1/Wg:M-[IDU]*
so that arguments with whitespace after them work correctly.
Resolves [toolchain/18248] from Andrew White at Motorola.
Be consisent in this syntax; previously we'd sometimes we'd just have :M-[ID]*
which would ignore -Ufoo ...
(This needs :C///W support in make(1) that Simon Gerraty added for me :)
* Don't bother prefixing commands with a line of ${_MKCMD}\
and instead rely upon "make -s". This is less intrusive on
all the Makefiles than the former. Idea from David Laight.
* Rename the variables use to print messages. The scheme now is:
_MKMSG_FOO Run _MKMSG 'foo'
_MKTARGET_FOO Run _MKMSG_FOO ${.TARGET}
From discussion with Alistair Crooks.
${_MKMSG} " ... {$.TARGET}" and use appropriately.
Provide _MKMSGLINK.m to provide "link" message by itself (without ${.TARGET})
Replace _MKSHCMD with _MKSHECHO
Supported values:
0 Minimal output ("quiet")
1 Describe what is occurring
2 Describe what is occurring and echo the actual command ("verbose")
This is the default, and is equivalent to the previous behaviour.
on the setting of ${SHLIBDIR} and ${SHLIBINSTALLDIR} (_not_ ${_LIBSODIR}).
Fixes cruel and unusual ^W^W^W obscure native-build and not-so-obscure
cross-builds problems I was having with shared libraries with a
non-base LIBDIR (e.g, /usr/X11R6/lib) that use LDADD to pull in other
libraries from /usr/lib (such as libm) which are really in /lib and the
symlink from ${DESTDIR}/usr/lib/libm.so to /lib/libm.so.N.M was confusing
the linker. Stuffing -rpath-link ${DESTDIR}/lib in solves the problem.
This should mean that shared libraries that depend upon other shared
libraries in other directories should DTRT in a DESTDIR (cross-)build...
Inspired by _PROGLDOPTS in <bsd.prog.mk>
* DPSRCS contains extra dependencies, but is _NOT_ added to CLEANFILES.
This is a change of behaviour. If a Makefile wants the clean semantics
it must specifically append to CLEANFILES.
Resolves PR toolchain/5204.
* To recap: .d (depend) files are generated for all files in SRCS and DPSRCS
that have a suffix of: .c .m .s .S .C .cc .cpp .cxx
* If YHEADER is set, automatically add the .y->.h to DPSRCS & CLEANFILES
* Ensure that ${OBJS} ${POBJS} ${LOBJS} ${SOBJS} *.d depend upon ${DPSRCS}
* Deprecate the (short lived) DEPENDSRCS
Update the various Makefiles to these new semantics; generally either
adding to CLEANFILES (because DPSRCS doesn't do that anymore), or replacing
specific .o dependencies with DPSRCS entries.
Tested with "make -j 8 distribution" and "make distribution".
only list the (often complicated) ${COMPILE.*} rules once always building
to ${.TARGET}.tmp. Then, depending on whether *OPTS has -g, either
"mv ${.TARGET}.tmp ${.TARGET}" or "${LD} -[xX] -r ${TARGET}.tmp -o ${.TARGET}"
as appropriate.
This can prevent inconsistency that could occur between "echo ${COMPILE.*:Q}"
and "${COMPILE.*}", such as the problem in rev 1.226. (There were still
examples of this in .cc.so and .m.so !!!)
Remove `@' from most non-echo rules, so that we can actually see what's
happening. This helps debugging problems, such as that fixed by rev 1.226.
Always remove all possible temp files that might occur because of the above.
Be consistent about ${CC} instead of $(CC)
includes. for GCC3, set this to -I instead of -isystem.
XXX this should really be either not required or a -isystem-cxx, but for
now this is required to build libstdc++-v3, which otherwise complains
heavily about STL headers not being C code(!)
COPTS.<fn> Additional flags to the compiler when creating the C objects
for <fn>.
CPUFLAGS.<fn> Additional flags to the compiler/assembler for <fn>.
CPPFLAGS.<fn> Additional flags to the C pre-processor for <fn>.
(For <fn>.[ly], "<fn>.c" must be used.)
(g)cc has all the knowledge which startfiles/libgcc to
use, so we don't need to duplicate all that here.
Externally visible change:
Shared objects are linked against libgcc_pic.a now
(if the in-tree gcc2 is used). This fixes problems with
dlopen()'ed objects referencing libgcc functions not used
(thus not linked in) by the main program.
christos