mirror of
https://github.com/YellowJacketLinux/LFS.git
synced 2025-01-23 22:42:17 +08:00
413556fd3a
* spell check * Prep for new README * Work on the new README * FHS notes added * tweaks * GLibC bootstrap subversion etc. * layers * not needed * work on layers * rename * layers work * rename multilib * rename again * more file renaming * stuff * link fixes etc. * cleaning up a bit * spell fixes etc. * nuke un-needed * fips note * spellfix * started TOS * ToC work
77 lines
3.0 KiB
Markdown
77 lines
3.0 KiB
Markdown
Filesystem Hierarchy Standard Note
|
|
==================================
|
|
|
|
In the FHS, `/{,s}bin` *may* be a symlink to `/usr/{,s}bin` and
|
|
`/lib{,64}` *may* be a symlink to `/usr/lib{,64}`.
|
|
|
|
Many modern Linux distributions do in fact implement those directories
|
|
as symbolic links.
|
|
|
|
For an RPM `.spec` file to truly be portable, it can not assume that
|
|
those directories are symbolic links and binaries/libraries that belong
|
|
within `/bin`, `/sbin`, `/lib`, and `/lib64` when they are not symbolic
|
|
links should be installed in those directories and not under the `/usr`
|
|
prefix.
|
|
|
|
For binaries within `/{,s}bin`, any shared libraries they link against
|
|
*must* be installed within `/lib{,64}` so that the binary will work in
|
|
the event `/usr` is a separate partition that is not mounted.
|
|
|
|
Shared Library Packaging
|
|
------------------------
|
|
|
|
For the shared libraries installed within `/lib`, I am choosing to put
|
|
the developer `libfoo.so` symbolic link and (if packaged) the developer
|
|
`libfoo.a` static library within `/usr/lib` even though the shared
|
|
library itself is within `/lib` and not under the `/usr` prefix. Those
|
|
files are not needed in the event `/usr` is not available.
|
|
|
|
With a very few exceptions (e.g. `libgcc_s` and `libstdc++` from `gcc`)
|
|
the way I do this is to pass
|
|
|
|
--libdir=/%{_lib}
|
|
|
|
to the configure script.
|
|
|
|
That does result in the shared library being placed within `/lib`
|
|
but *usually* it also results in the `pkgconfig` directory also being
|
|
placed in `/lib` along with `foolib.so` and (if built) `foolib.a`.
|
|
Furthermore, the `foolib.pc` points to `/lib` for linking, which
|
|
technically is correct if that is where the `foolib.so` and `foolib.a`
|
|
files are located. However I do not want them in `/lib`.
|
|
|
|
In a *very few* cases, the resulting `Makefile` is smart enough to do
|
|
what I want (put `foolib.so` in `/usr/lib` and `foo.pc` in
|
|
`/usr/lib/pkgconfig` correctly configured) but usually I do have to
|
|
manually adjust the install.
|
|
|
|
An example from the `zlib.spec` file:
|
|
|
|
install -m755 -d %{buildroot}%{_libdir}
|
|
sed -i 's?libdir=.*?libdir=%{_libdir}?' %{buildroot}/%{_lib}/pkgconfig/zlib.pc
|
|
mv %{buildroot}/%{_lib}/pkgconfig %{buildroot}%{_libdir}/
|
|
rm -f %{buildroot}/%{_lib}/libz.so
|
|
ln -s ../../%{_lib}/libz.so.1.2.13 %{buildroot}%{_libdir}/libz.so
|
|
# just in case we ever package the static library
|
|
mv %{buildroot}/%{_lib}/libz.a %{buildroot}%{_libdir}/
|
|
|
|
The `install` commands creates `/usr/lib`, the `sed` command fixes the
|
|
`zlib.pc` file and then the `pkgconfig` directory is put in the proper
|
|
place.
|
|
|
|
The original `/lib/libz.so` symbolic link is deleted, and a new one is
|
|
created within `/usr/lib` that points to the actual library that is
|
|
still within `/lib`.
|
|
|
|
Even though I am not currently packaging the `libz.a` static library,
|
|
it is moved into `/usr/lib` just in case there ever arises a legitimate
|
|
use case to package the static library.
|
|
|
|
Within the `%files devel` section, I exclude it from being packages:
|
|
|
|
%exclude %{_libdir}/libz.a
|
|
|
|
Most shared libraries belong in `/usr/lib` and this adjustment is not
|
|
necessary.
|
|
|