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
in which the source code is written. This is controlled by the CSTD
variable, which can have one of the following values:
- "k&r" => -traditional
- "c89" or "c90" => -std=iso9899:1990
- "c94" or "c95" => -std=iso9899:199409
- "c99" => -std=iso9899:1999
The corresponding option is added to CFLAGS regardless of WARNS level.
This also removes -ansi from WARNS level 6, but adds -Wno-long-long to
work around a weird gcc bug (-ansi, which is supposedly equivalent to
-std=iso9899:1990, seems to turn long long warnings off instead of on)
If CSTD is undefined, CFLAGS are unchanged except for the -ansi /
-Wno-long-long change mentioned above for WARNS level 6.
FreeBSD. This method attempts to centralize all the necessary hacks
or work arounds in one of two places in the tree (src/Makefile.inc1
and src/tools/build). We build a small compatibility library
(libbuild.a) as well as selectively installing necessary include
files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various
places in the tree. We still build on tip of stable and current. I
will work with those that want to support more, although I anticipate
it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at
various stage of implementation, as well as for working together to
positively effect a change for the better.
glibc which is externally maintained, so GCC ships with these
warnings turned off by default. This is also consistent with
the src/contrib/gcc/c-lex.c,v 1.2 change.
Always use sys/conf/kern.mk when building kernel/modules.
<bsd.kern.mk> is only preserved for sys/boot/pc98/boot2
for now, but this will be fixed. If there are other
users of <bsd.kern.mk>, please let me know.
Reminded by: bde
for the -static flag instead when constructing LIBPAM.
(This fixes false warnings from ``make checkdpadd -DNOSHARED'' in
lib/libpam/modules/.)
Submitted by: bde, ru
Approved by: re
Don't gratuitously pipe thru a cat(1) if NODOCCOMPRESS.
Only create _stamp.extra when necessary.
Get rid of SOELIMPP and OBJS.
Use Groff version of soelim(1); we need its -I option
for the following to work.
Don't needlessly chdir to SRCDIR. Only a few documents
need CD_HACK, and those that need it either use refer(1)
or .PSPIC macro which internally uses the .psbb call.
to creating the tags file using ctags(1). Defaults to "gtags".
Made GTAGSFLAGS and HTAGSFLAGS overrideable, added CTAGSFLAGS.
Folded bsd.prog.mk version of `tags' into bsd.dep.mk.
PR: bin/42852
Fix the "@gprel relocation against dynamic symbol xxx" linker error.
Variables defined in the link unit and small enough to be put in the
short data section will have a gp-relative access sequence (using the
@gprel relocation). It is invalid to have @gprel relocations in shared
libraries, because they are to be resolved by the static linker and
not the dynamic linker. The -fpic option will cause @ltoff relocations
for @gprel relocations, but the side-effects are untested (if any).
Instead, disable/eliminate the short data section to achieve the same.
In "nroff" mode, italic font renders as an underlined text, which
makes it indistinguishable from the bold text on color monitors
(cons25 terminal type), yet it requires the less(1)'s -R option.
(Refer to the new grotty(1) manpage for details.)
So turn off the color support for now (when generating catpages),
until we figure out what do we do with this new feature. I have
a patch for grotty(1) that tells it to use the "reverse video"
attribute to render the italic font. Once this is accepted, we
can turn color support back on (if there won't be any objections
from the community).
This reduces the size of GENERIC's text space by 73999 bytes (about 2%).
The bloat is from approximately 3437 strings longer than 31 characters
being padded to a 32-byte boundary.
o Make it possible to prevent parts of the tree from being linted
(say) during a 'make world' by setting NOLINT in a leaf Makefile.
o Make "make lint" work (better) for executable programs.
o Clean up (nuke!) a syntax damaged pipeline.
lowest value in order to get the right MACHINE_CPU values since setting
CPUTYPE can result in problems later in the buildkernel case. Instead,
set MACHINE_CPU directly and leave CPUTYPE alone.
Tested by: mbr
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
ev6 or pca56 etc this downgrades the cpu specification passed to gas.
As a result, gas will fail when gcc generates media instructions (in
uipc_usrreq.c). This only affects what gas will accept, not what gcc
generates or what our *.s file contain.
TARGET_ARCH and TARGET. This is problematic when one has the =
(unconditional) type of assigment for CPUTYPE in /etc/make.conf.
(This would override what was set on the command line to "make
buildworld".)
Add a (horrible) kludge to Makefile.inc1 to check the type of
assignment for CPUTYPE (only for those who attempts to set it to
a different value). Fix an example make.conf. Fix the kernel's
build-tools target (aicasm only at the moment) to catch up with
bsd.cpu.mk,v 1.15 (BOOTSTRAPPING replaced with NO_CPU_CFLAGS in
Makefile.inc1's BMAKE).
Reviewed by: jhb
bsd.cpu.mk doesn't have to worry about compilers other than the current
version.
- Allow TARGET_CPUTYPE to override CPUTYPE in bsd.cpu.mk.
- Treat an empty CPUTYPE the same as an undefined CPUTYPE.
- For buildworld, buildkernel, etc., define TARGET_CPUTYPE to CPUTYPE for
native builds and define it to be empty for cross-builds.
TARGET_CPUTYPE is only defined if it is not already defined via the
commandline or environment.
- To minimize whitespace changes, remove a test that didn't define
_CPUCFLAGS if both NO_CPU_CFLAGS and NO_CPU_COPTFLAGS were defined
since it is redundant (we don't use _CPUCFLAGS if those are defined).
to tune for more advanced processors while still supporting the minimum
processor in an architecture. We can do this with the '-mtune=' option
to gcc for alpha, sparc64, and powerpc and with the mis-named '-mcpu='
option for i386.
This defaults to tuning i386 builds for i686 machines though not using
any instructions that aren't found on an 80386. For alpha it defaults
to tuning for an EV5.
Approved by: peter
Peril sensitive sunglasses borrowed from: peter
