Xen devel - Aug 2006 - why is blktap statically linking it''s drivers?

It took me a bit to realize that the issue I was having with blktap
compiling in xen-unstable is that it is statically linking libcrypto and
libc into all of the executables in: xen-unstable/tools/blktap/drivers

Is there a reason for this?  It means that every one of those executables
ends up at > 1 MB, which seems quite excessive.  It also means that you need
static-devel packages on some distros, which tend to not be installed by
default.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center                     email: japh@us.ibm.com
Open Hypervisor Team                           alt: sldague@us.ibm.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 4/8/06 7:19 pm, "Sean Dague" <japh@us.ibm.com> wrote:
> It took me a bit to realize that the issue I was having with blktap
> compiling in xen-unstable is that it is statically linking libcrypto and
> libc into all of the executables in: xen-unstable/tools/blktap/drivers
> 
> Is there a reason for this?  It means that every one of those executables
> ends up at > 1 MB, which seems quite excessive.  It also means that you
need
> static-devel packages on some distros, which tend to not be installed by
> default.
I *think* the intention is to statically link to our own copy of libaio, but
the -static flag causes us to statically link against all libraries. The
correct thing might be to explicitly link in libaio.a and remove -static,
but Julian will know better than me.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 4 Aug 2006, at 20:26, Keir Fraser wrote:
>
> On 4/8/06 7:19 pm, "Sean Dague" <japh@us.ibm.com> wrote:
>
>> It took me a bit to realize that the issue I was having with blktap
>> compiling in xen-unstable is that it is statically linking libcrypto 
>> and
>> libc into all of the executables in: xen-unstable/tools/blktap/drivers
>>
>> Is there a reason for this?  It means that every one of those 
>> executables
>> ends up at > 1 MB, which seems quite excessive.  It also means that 
>> you need
>> static-devel packages on some distros, which tend to not be installed 
>> by
>> default.
>
> I *think* the intention is to statically link to our own copy of 
> libaio, but
> the -static flag causes us to statically link against all libraries. 
> The
> correct thing might be to explicitly link in libaio.a and remove 
> -static,
> but Julian will know better than me.
Yep that''s correct, we wanted to avoid libaio conflicts. I''ll
push an
update to the Makefile today.

- Julian
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 2006-08-04 at 14:19 -0400, Sean Dague wrote:
> It took me a bit to realize that the issue I was having with blktap
> compiling in xen-unstable is that it is statically linking libcrypto and
> libc into all of the executables in: xen-unstable/tools/blktap/drivers
> 
> Is there a reason for this?  It means that every one of those executables
> ends up at > 1 MB, which seems quite excessive.  It also means that you
need
> static-devel packages on some distros, which tend to not be installed by
> default.
I am a great fan of static linking, because it is the only simple
solution to ''DLL hell'' (which I find to be a greater problem
on Linux
now than on Windows), and because it allows simple installation of
binaries to remote machines and places where I do not have root-access.
Most commercial software also comes in static versions, as this is the
only reasonable way to deal with the n-distros problem. Finally,
statically linked applications load faster because all the linking has
been done ahead of time.

Unfortunately GNU ld does a very poor job of eliminating unreachable
code, and when combined with the bloated glibc you end up with such
enourmous binaries. Other linkers, e.g. Microsoft''s linker on Windows
and SN System''s own linker which is used by most game developers prove
that it is possible to perform much better than ld. Another option is to
shun glibc in favor of a stripped-down libc such as uClibc, newlib or
dietlibc. I recently played with uClibc for my own tools, and one went
from 500kB down to 22kB just by replacing glibc with uclibc''s version.

I hope that in the future GNU ld will improve (or perhaps the OpenWatcom
linker may be used instead), and that distro maintainers will remember
to ship .a versions of libraries, so that static linking keeps being an
option.

Regards,
Jacob


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/08/06 22:47 -0700, Jacob Gorm Hansen wrote:
>
>I hope that in the future GNU ld will improve (or perhaps the OpenWatcom
>linker may be used instead), and that distro maintainers will remember
>to ship .a versions of libraries, so that static linking keeps being an
>option.
Wow, Watcom takes me back to my netware days, although we used the phar lap
linker back then.

Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel