module-init-tools --enable-zlib-dynamic
Bruce Dubbs
bruce.dubbs at gmail.com
Mon Jun 22 18:13:18 MDT 2009
DJ Lucas wrote:
> Tobias Gasser wrote:
>> Gilles Espinasse schrieb:
>>
>>>> i don't link anything static. i move all .a files out of the library
>>>> path if there is a corresponding .so available.
>>>>
>>>> excptions are the modutils package (which require libc and libz to be
>>>> linked static), and sysvinit (libcrypt) where i copy the static
>>>> libraries back during the build.
>>>>
>>>>
>>> that's no more true concerning libz.
>>> On module-init-tools-3.8, there is a new --enable-zlib-dynamic parameter.
>>> insmod,rmmod,modprobe are much smaller without static libz.
Well, insmod is 30K, rmmod is 34K, modprobe is 175K now. With a dynamic zlib,
we save about 85K on those three files.
>> should we add this option to chapter 6.48.1?
>>
>> probably with some comment about /usr/lib must be on the root partition
>> to be able to access the tools during bootup.
>>
> And I thought that I had been complaining on this long enough so that we
> would never violate the FHS again. ;-) Even as rare as a remote /usr
> mount is now days, libz really must be moved to /lib if anything in /bin
> or /sbin links against it if we are to follow the FHS.
Using dynamic zlib really doesn't save that much space unless you are trying to
create a really, really small footprint. For the vast majority of people, the
space saved is insignificant.
As DJ says, using a dynamic zlib causes cascading effects because we then have
to move libz to /lib which can cause issues for someone doing configuration
control vi a nfs mounted /usr partition.
Another issue is that if zlib is upgraded improperly, it could hose module
loading and thus the whole system. It would be very difficult to find the
problem.
These are trade offs that have to be made. I don't think saving the space being
discussed is worth the multiple changes and risks required. For me, I use a
total of 2 modules, vmware and nvidia, and then only because I need the
proprietary drivers.
-- Bruce
More information about the lfs-dev
mailing list