form became unnecessary with the bsd.prog.mk,v 1.69 change.
- Eliminated duplicate y.tab.h in SRCS.
Reviewed by: bde
- Complementary to the said bsd.prog.mk change, use the fact
that inner .for loops are not real loops but a tricky form
of a local macro for the outer loop's variable, and switch
to using faster variable modifiers to replace extensions.
libraries to be reported as up-to-date.
Before:
# make -f /dev/null nonexistent.a
`nonexistent.a' is up to date.
After:
# make -f /dev/null nonexistent.a
make: don't know how to make nonexistent.a. Stop
PR: bin/44137 (part of)
as it was decided that our toolchain will revert to looking
for libraries in /usr/lib only.
- Make /usr/lib/libfoo.so -> /lib/libfoo.so.X symlinks absolute
so that they still work if /usr is symlinked.
- Remove stale /usr/lib/libfoo.so.X libraries during install.
Discussed with: gordon, obrien, peter
hose your system. You end up with just about everything statically linked
(except for libpam.so), which then causes all the pam users to fail.
eg: login, sshd, su etc all stop working because dlopen no longer works
because there is no libc.so in memory anymore.
gcc passes -L/usr/lib to ld. The /usr/lib/libxxx.so symlink is *not* a
compatability link. It is actually the primary link. There should be no
symlinks in /lib at all. Only /lib/libXX.so.Y.
peter@daintree[9:27pm]/usr/bin-104> file yppasswd
yppasswd: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 5.1.1, dynamically linked (uses shared libs), stripped
peter@daintree[9:27pm]/usr/bin-105> ldd yppasswd
yppasswd:
libpam.so.2 => /usr/lib/libpam.so.2 (0x280d1000)
peter@daintree[9:28pm]/usr/bin-106>
Note no libc.so.5. Hence libpam.so.2 has unresolved dependencies.
I believe this is also the cause of the recent buildworld failures when
pam_krb5.so references -lcrypto stuff etc and when librpcsvc.so references
des_setparity() etc.
This change could not possibly have worked, unless there are other missing
changes to the gcc configuration. It won't work with ports versions of
gcc either.
are created in the correct location. Always make them. For libraries
that live in /lib, this causes a /lib/libfoo.so and a compatibility
/usr/lib/libfoo.so to be created. We may want to drop the
/usr/lib/libfoo.so symlink at some future point.
need relative pathing to work correctly. This is s necessary step
for putting libraries in /lib while the .so symlinks still live
in /usr/lib.
This should be a big NOOP in the case where SHLIBDIR == LIBDIR.
This is simpler, and is easy to do now that make(1) supports substituting
regexps. Fixed missing '$' anchor in the regexp. Use less cryptic names
for temporary variables.
Submitted by: ru (early version)
Reviewed by: ru
All .s files that need cpp(1) processing (see gcc(1) manpage's
DESCRIPTION section) have been repo-copied to .S files. This
is mostly to bring bsd.lib.mk in agreement with sys.mk.
Desired by: obrien
symbols from object files has bitrotted over the last
thirteen years, and it now does more harm than good.
An attempt to work around the problems caused by using
ld(1) for stripping was to pass LDFLAGS to the ld(1)
command, but this was not right either as ${LDFLAGS}
should, by design, be used with cc(1) and not ld(1).
One of the proposed solutions was to use the objcopy(1)
utility to do the strip work, and the other would be to
use strip(1), but Bruce Evans suggested not stripping
any symbols at all. This works by leaving the grunt
work to the final strip(1) command (when installing the
binary).
Submitted by: bde
components. This is generally considered a non-optimal solution but
it gets the job done for the /rescue case.
Submitted by: Tim Kientzle <kientzle@acm.org>
uses alloca() and alloca is impossible to implement as a callable function
on amd64. It has to be a compiler builtin. Note that the bigger problem
is that libc is not c99 clean internally.
known to produce broken code with -march=pentium4. Add a note explaining this.
This should be removed when we update to gcc 3.3 or the bug is otherwise fixed.
Approved by: re
