Re: [ANNOUNCE] udev 048 release

From: Tomasz Kłoczko
Date: Wed Dec 08 2004 - 18:28:49 EST

On Wed, 8 Dec 2004, Greg KH wrote:

On Wed, Dec 08, 2004 at 10:56:27PM +0100, Tomasz K?oczko wrote:

First: is it any real reason for use by udev private copy libsysfs which
is statically linked with udev ?

Yes, the "system" version of libsysfs is not always the same one that
udev wants.

Sorry but from eons spend some time on prepare correct build enviromet isn't task for each project maintainers but for persons who tries buid specified project from source tree :-|

Try prepare in corect form only udev .. and nothing more :_)

Me and probaly many othet people aroud the word who tries build variose
tools for variouse distributions hates maintainers who includes in project tree souce code another projects. Much more haten is project maitainer who don't allow in easy way use system avalaible libraries.
Please don't try be listed on this long hated maintainers list ;>

Argument allways is like yours .. and allways this is source ass pain
for distribution maintainers like:

- patchin from each new version for use system avalaible libraries if
something will be changed in build automations (for udev from may this
year it hapens .. seven times),

- what if in libsysfs will be discovered some nasty bug ? Why I must audit
not only libsysfs but also any other projests where libsysfs source was
included ? (this not hipotetycal case .. do you remember case with for
example with security bugs in zlib ?).

If you want more argumets for not link statisally look at Solarias 10 why *ALL* binaries are linked with shared version of any library and lern more .. this is _specialy_ for tools very close to kernel layer.

I'm using udev with shared libsysfs for a months and all works correcly.

Great. Notice any code size savings? Yeah, it's not really all that
much. You also need static linking when using klibc to get a very tiny
udev for your boot initramfs image.

This not for code saving but for use only one copy of library by any tools which uses specifieed API/ABI. In case any bug on for example libsysfs
which can be fixed without changing API/API all what must be performed is
replace libsysfs shared library .. nothing more.

It makes harder packaging udev if someone will try generate udev in
for example rpm form with debug info in separated udev-debug package.

I'm sure those who package up rpms of udev have dealt with this properly
somehow. For the rest of the world, I'd prefer to keep the current way.

Greg meybe you are very good kernel hacker (for me you are :) but seems you are not so good as person for maintaining user space tools ;>

IMO ony ~1-2% of *all* project uses direct stripping chained directly chained in build automation which is used by default. All from this ~1-2% because maintainer isn't skilled in some subjects.
Default behavior ~99-98% projects build automations is pass not stripped
binaries. On most of this projects (all which uses for example automake)
producing stripped binaries cen be enabled by add -s to linking options
(usualy LDFLAGS="-s").

*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
Tomasz Kłoczko, sys adm|*e-mail: kloczek@xxxxxxxxxxxxxxxxxx*