Garrick Staples wrote:

On Wed, Jan 09, 2008 at 02:00:13PM +1300, Clint Dilks alleged:

...

Hi People

I am trying to build a piece of software from source in this case aide 0.13.1 using this config line ./configure --with-zlib --with-selinux. The configure step completes but there is a Warning that concerns me. This is taken from config.log

configure:9809: checking for mhash_get_block_size in -lmhash configure:9844: gcc -o conftest -g -O2 -static -static conftest.c -lmhash -lz >&5 /usr/bin/ld: cannot find -lmhash collect2: ld returned 1 exit status

The '-static' means that the linker needs to find a static library archive to create a static executable. That means it wants to find /usr/lib/libmhash.a. Without the '-static', it would look for the shared library, libmhash.so.

The mhash-devel package doesn't contain libmhash.a, so your test linking fails.

It has been fedora/upstream policy for while to discourage the packaging of static archive files. I'm sure the Fedora wiki has a page explaining why, but I'm too lazy to find it right now.

---

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Thanks, that was it. :)

For those who might be interested this is link from Fedora Wiki that offers some incite

http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage?highlight=%28Sta... http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges?highlight...

On Tue, 2008-01-08 at 21:43 -0800, Michael A. Peters wrote:

<snip>

I don't know what reasons the wiki gives, but if a bug (security or other) exists in a library and you statically link against it, then when that bug is fixed - you have to rebuild all apps that linked against the static lib or they will continue to contain the bug even, even when the library is updated. With shared libraries, that isn't an issue. With shared libraries, updating the library is all you need to do.

<disclaimer> I believe in shared libraries and disavow any proclivity towards static linking as an SOP. However ... </disclaimer>

Just to add a little balance to the mix, I want to point out that if a *really* secure and stable environment is needed and is managed by an attentive and highly competent administrator, the static link avoids the pitfall that besets shared libraries. If a shared library with a major flaw - especially security related - is installed, the potential problem instantly propagates to every application using that library.

As has been detailed, so do the fixes.

OTH, an application(s) that is(are) statically linked may be re-linked and used as a test vehicle(s) before general application of the updated library is begun. Although *not* an assurance of stability and correct operation, this can permit a *relatively* more secure and stable environment.

The downsides are obvious. The benefits less so. The environment should determine the choice, with proper balance of cost vs. benefit.

No discussion of imprecise overhead estimates need be posted here. All are well known and fall under the category of evaluation in a cost/benefit scenario.

zlib I believe was a real world example of this - some years ago (red hat 5 ??), zlib was found to have a bug that could potentially be exploited. A lot of apps linked against the static library. Even after zlib had been updated, those apps were still vulnerable until they were recompiled.

And of course, the flip side is that if shared libraries had been in use, all applications that linked to it would have been immediately vulnerable.

The longer the time from the dissemination of the flaw to the dissemination of the fix, the greater the window of opportunity for black hats and/or disastrous corruption.

<snip sig stuff>