Bug#423182: numactl: should compile libnuma.a
Hi,
Ian Wienand, le Tue 15 May 2007 10:04:57 +1000, a écrit :
On 5/14/07, Brice.Goglin [EMAIL PROTECTED] wrote:
libnuma does not depend on the kernel interface as much as libc6 does,
but libc6-dev does provide libc.a.
The only argument I really buy is that static libraries can be faster,
Ok.
I don't see what part of libnuma could be on the critical-path
(and if it is, the extra jump will be nothing compared to the
overheads of allocating/migrating/pinning memory, etc).
Agreed.
libc could conceivably be on the critical-path of an application
...
And libc is far from being alone. Having to specify by hand (i.e.
giving the full .a path) all libraries that should get linked statically
is quite tedious, particularly since you have to specify the full path,
which can depend on the setup (/usr/local/, /opt/, ...), so just giving
-static is what people always do.
IMO you're doing yourself a dis-service by not using it as a shared
library; you can can't get the advantages of code sharing,
In high-performance computing case, usually only one application is
running on the machine (and libnuma is not so big ;) ).
you can easily miss bug fix updates, you open yourself to bugs from
version skew, etc.
As I said, people who use -static generally keep recompiling their
application, so that's fine.
If we send a patch, would you apply it?
I want the package to be useful, and if not having a static library is
making your life difficult
It is indeed. Here is a patch.
Thanks,
Samuel
diff -ur numactl-0.9.11/Makefile numactl-0.9.11-mine/Makefile
--- numactl-0.9.11/Makefile 2006-10-31 01:10:26.0 +0100
+++ numactl-0.9.11-mine/Makefile2007-05-15 09:19:13.0 +0200
@@ -17,7 +17,7 @@
endif
CLEANFILES := numactl.o libnuma.o numactl numademo numademo.o distance.o \
- memhog libnuma.so libnuma.so.1 numamon numamon.o syscall.o
bitops.o \
+ memhog libnuma.so libnuma.so.1 libnuma.a numamon numamon.o
syscall.o bitops.o \
memhog.o util.o stream_main.o stream_lib.o shm.o stream \
test/pagesize test/tshared test/mynode.o test/tshared.o mt.o \
test/mynode test/ftok test/prefered test/randmap \
@@ -66,6 +66,10 @@
libnuma.so.1: libnuma.o syscall.o distance.o
${CC} -shared -Wl,-soname=libnuma.so.1 -o libnuma.so.1 $^
+libnuma.a: libnuma.o syscall.o distance.o
+ ar rc $@ $^
+ ranlib $@
+
libnuma.so: libnuma.so.1
ln -sf libnuma.so.1 libnuma.so
@@ -106,7 +110,7 @@
MANPAGES := numa.3 numactl.8 numastat.8 migratepages.8
-install: numactl migratepages numademo.c numamon memhog libnuma.so.1 numa.h
numaif.h numastat ${MANPAGES}
+install: numactl migratepages numademo.c numamon memhog libnuma.so.1 libnuma.a
numa.h numaif.h numastat ${MANPAGES}
mkdir -p ${prefix}/bin
cp numactl ${prefix}/bin
cp migratepages ${prefix}/bin
@@ -119,6 +123,7 @@
cp numa_maps.5 ${prefix}/share/man/man5
mkdir -p ${libdir}
cp libnuma.so.1 ${libdir}
+ cp libnuma.a ${libdir}
cd ${libdir} ; ln -sf libnuma.so.1 libnuma.so
mkdir -p ${prefix}/include
cp numa.h numaif.h ${prefix}/include
diff -ur numactl-0.9.11/debian/libnuma-dev.install
numactl-0.9.11-mine/debian/libnuma-dev.install
--- numactl-0.9.11/debian/libnuma-dev.install 2007-05-15 09:15:05.0
+0200
+++ numactl-0.9.11-mine/debian/libnuma-dev.install 2007-05-15
09:14:06.0 +0200
@@ -1,2 +1,3 @@
debian/tmp/usr/include/
debian/tmp/usr/lib/libnuma.so
+debian/tmp/usr/lib/libnuma.a
Bug#423182: numactl: should compile libnuma.a
Ian Wienand, le Mon 14 May 2007 13:58:38 +1000, a écrit : On Fri, May 11, 2007 at 10:26:53AM +0200, Samuel Thibault wrote: The upstream build doesn't actually create a static library, I'm pretty sure by design to avoid version skew, etc. Mm, what version skew problem could happen? Where the library changes due to kernel interfaces, etc. I asked upstream and the reply was I would prefer not. The library was always intended to be replaced under a program. Given the kernel interface has been fairly stable, but there can be always new features like cpuset support. Then one just needs to relink the application. In the case I mentioned (people that link statically for getting best performance), it is very far from a problem (people would do recompiles every day actually; some applications even need a recompile whenever data change). Samuel
Bug#423182: numactl: should compile libnuma.a
Hi, I agree with Samuel's request. A good reason to go against upstream wishes is that upstream is wrong :) Static libs are definitely very useful, and even sometimes required (when you want to link against a program that for some reason cannot be dynamically linked). And there is nothing specific in libnuma that could justify that almost all other lib packages provide static libs while libnuma does not. For instance, libnuma does not depend on the kernel interface as much as libc6 does, but libc6-dev does provide libc.a. If we send a patch, would you apply it? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423182: numactl: should compile libnuma.a
On 5/14/07, Brice.Goglin [EMAIL PROTECTED] wrote: libnuma does not depend on the kernel interface as much as libc6 does, but libc6-dev does provide libc.a. The only argument I really buy is that static libraries can be faster, and libc could conceivably be on the critical-path of an application ... I don't see what part of libnuma could be on the critical-path (and if it is, the extra jump will be nothing compared to the overheads of allocating/migrating/pinning memory, etc). IMO you're doing yourself a dis-service by not using it as a shared library; you can can't get the advantages of code sharing, you can easily miss bug fix updates, you open yourself to bugs from version skew, etc. If we send a patch, would you apply it? I want the package to be useful, and if not having a static library is making your life difficult I guess I don't have a choice but to provide it. But for *this* library, I just don't get why having it static helps anyone. -i -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423182: numactl: should compile libnuma.a
On Fri, May 11, 2007 at 10:26:53AM +0200, Samuel Thibault wrote: The upstream build doesn't actually create a static library, I'm pretty sure by design to avoid version skew, etc. Mm, what version skew problem could happen? Where the library changes due to kernel interfaces, etc. I asked upstream and the reply was I would prefer not. The library was always intended to be replaced under a program. Given the kernel interface has been fairly stable, but there can be always new features like cpuset support. In this case, I don't see any reason to go against upstreams wishes. Thanks, -i -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423182: numactl: should compile libnuma.a
Hi, Ian Wienand, le Fri 11 May 2007 11:15:30 +1000, a écrit : On 5/10/07, Samuel Thibault [EMAIL PROTECTED] wrote: There is no libnuma.a, but scientific applications typically compile statically and thus need libnuma.a, so Debian should provide it. Hi Samuel, The upstream build doesn't actually create a static library, I'm pretty sure by design to avoid version skew, etc. Mm, what version skew problem could happen? Personally I don't think it makes sense to build this library into your application. Do you have a particular reason for needing it static in your application? Because the applications I'm using here (scientific computation) want best achievable speed, and linking statically gives a fair boost. As a result, it's very usual to find those with -static hardwired in the Makefiles. Having to modify all applications' Makefile is somewhat tedious... Samuel
Bug#423182: numactl: should compile libnuma.a
Package: numactl Version: 0.9.11-3 Severity: wishlist Hi, There is no libnuma.a, but scientific applications typically compile statically and thus need libnuma.a, so Debian should provide it. Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages numactl depends on: ii libc6 2.5-7 GNU C Library: Shared libraries ii libnuma1 0.9.11-2 Libraries for controlling NUMA pol numactl recommends no packages. -- no debconf information -- Samuel Thibault [EMAIL PROTECTED] `When you say I wrote a program that crashed Windows, people just stare at you blankly and say Hey, I got those with the system, *for free*.' (By Linus Torvalds) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423182: numactl: should compile libnuma.a
On 5/10/07, Samuel Thibault [EMAIL PROTECTED] wrote: There is no libnuma.a, but scientific applications typically compile statically and thus need libnuma.a, so Debian should provide it. Hi Samuel, The upstream build doesn't actually create a static library, I'm pretty sure by design to avoid version skew, etc. Personally I don't think it makes sense to build this library into your application. Do you have a particular reason for needing it static in your application? Cheers, -i -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
