[PATCH 2/4] check whether to add -lm for testing to compile
Hi, Linux needs -lm in order to compile the testing directory due to fabs(). ciao, Mario Index: configure.ac =================================================================== --- configure.ac (Revision 171) +++ configure.ac (Arbeitskopie) @@ -138,6 +138,7 @@ # AC_SEARCH_LIBS(clock_gettime, rt) AC_SEARCH_LIBS(pthread_create, pthread) +AC_SEARCH_LIBS(fabs, m) # # Prefer native kqueue(2); otherwise use libkqueue if present.
On Wed, 18 Nov 2009, Mario Schwalbe wrote:
Linux needs -lm in order to compile the testing directory due to fabs().
Could you confirm that this doesn't create an unnecessary libm dependency for libdispatch itself? Robert N M Watson Computer Laboratory University of Cambridge
ciao, Mario
Index: configure.ac =================================================================== --- configure.ac (Revision 171) +++ configure.ac (Arbeitskopie) @@ -138,6 +138,7 @@ # AC_SEARCH_LIBS(clock_gettime, rt) AC_SEARCH_LIBS(pthread_create, pthread) +AC_SEARCH_LIBS(fabs, m)
# # Prefer native kqueue(2); otherwise use libkqueue if present. _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Hi, Robert Watson schrieb:
On Wed, 18 Nov 2009, Mario Schwalbe wrote:
Linux needs -lm in order to compile the testing directory due to fabs(). Could you confirm that this doesn't create an unnecessary libm dependency for libdispatch itself?
No, it does create a superfluous dependency. # ldd install/libdispatch-{gcc,llvm-gcc}/lib/libdispatch.so install/libdispatch-gcc/lib/libdispatch.so: linux-vdso.so.1 => (0x00007fff007ff000) libkqueue.so => /home/mario/diplom/install/libkqueue/lib/libkqueue.so (0x00007f9f49893000) libm.so.6 => /lib/libm.so.6 (0x00007f9f495e3000) librt.so.1 => /lib/librt.so.1 (0x00007f9f493da000) libc.so.6 => /lib/libc.so.6 (0x00007f9f4906b000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f9f48e4f000) /lib64/ld-linux-x86-64.so.2 (0x00007f9f49cb0000) install/libdispatch-llvm-gcc/lib/libdispatch.so: linux-vdso.so.1 => (0x00007fffcadff000) libkqueue.so => /home/mario/diplom/install/libkqueue/lib/libkqueue.so (0x00007f6b3e72a000) libm.so.6 => /lib/libm.so.6 (0x00007f6b3e47a000) librt.so.1 => /lib/librt.so.1 (0x00007f6b3e271000) libBlocksRuntime.so => not found libc.so.6 => /lib/libc.so.6 (0x00007f6b3df02000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6b3dce5000) /lib64/ld-linux-x86-64.so.2 (0x00007f6b3eb48000) The patch should have been: Index: configure.ac =================================================================== --- configure.ac (Revision 171) +++ configure.ac (Arbeitskopie) @@ -138,6 +138,7 @@ # AC_SEARCH_LIBS(clock_gettime, rt) AC_SEARCH_LIBS(pthread_create, pthread) +LT_LIB_M # # Prefer native kqueue(2); otherwise use libkqueue if present. Index: testing/Makefile.am =================================================================== --- testing/Makefile.am (Revision 171) +++ testing/Makefile.am (Arbeitskopie) @@ -33,6 +33,7 @@ dispatch_sema \ dispatch_timer_bit31 \ dispatch_timer_bit63 +dispatch_drift_LDFLAGS=$(LIBM) endif TESTS+=$(CBLOCKS_TESTS)
On Wed, 18 Nov 2009, Mario Schwalbe wrote:
Robert Watson schrieb:
On Wed, 18 Nov 2009, Mario Schwalbe wrote:
Linux needs -lm in order to compile the testing directory due to fabs(). Could you confirm that this doesn't create an unnecessary libm dependency for libdispatch itself?
No, it does create a superfluous dependency.
Another possibility, since libm isn't required on FreeBSD or Mac OS X for fabs(), would be to use AC_CHECK_FUNC() to see if it's available without special linkage. If it isn't, then as custom action, use AC_SEARCH_LIBS(), itself with a custom action that adds -lm only to FABS_LIBS, which can be used just with the binary that requires it. This avoids picking up libm dependencies on the testing binaries as well; if we hit any interesting platforms that don't implement fabs() at all (are there any?) then we could also use it to trigger conditional building of the test. Robert N M Watson Computer Laboratory University of Cambridge
Hi, Robert Watson schrieb:
On Wed, 18 Nov 2009, Mario Schwalbe wrote:
Robert Watson schrieb:
On Wed, 18 Nov 2009, Mario Schwalbe wrote:
Linux needs -lm in order to compile the testing directory due to fabs(). Could you confirm that this doesn't create an unnecessary libm dependency for libdispatch itself? No, it does create a superfluous dependency. Another possibility, since libm isn't required on FreeBSD or Mac OS X for fabs(), would be to use AC_CHECK_FUNC() to see if it's available without special linkage. If it isn't, then as custom action, use AC_SEARCH_LIBS(), itself with a custom action that adds -lm only to FABS_LIBS, which can be used just with the binary that requires it.
I thought this is what LT_LIB_M does already, as it adds -lm or -lmw to LIBM on systems that require it. This variable in turn can be used just with the binary that requires it. What's the difference?
This avoids picking up libm dependencies on the testing binaries as well;
How? It's still a separate variable that must be used somewhere to have any effect.
if we hit any interesting platforms that don't implement fabs() at all (are there any?) then we could also use it to trigger conditional building of the test.
That's very unlikely, isn't it?
On 11/18/2009 04:50 PM, Mario Schwalbe wrote:
I thought this is what LT_LIB_M does already, as it adds -lm or -lmw to LIBM on systems that require it. This variable in turn can be used just with the binary that requires it. What's the difference?
FWIW, I agree that LT_LIB_M is a good choice. Paolo
On Wed, 18 Nov 2009, Paolo Bonzini wrote:
On 11/18/2009 04:50 PM, Mario Schwalbe wrote:
I thought this is what LT_LIB_M does already, as it adds -lm or -lmw to LIBM on systems that require it. This variable in turn can be used just with the binary that requires it. What's the difference?
FWIW, I agree that LT_LIB_M is a good choice.
Has anyone else noticed that getting libdispatch to run on a new OS is the easy bit, and that figuring out the auto*/libtool/pkg-config/etc stuff is the hard bit? :-) I'll go with the LT_LIB_M route as-submitted. Robert N M Watson Computer Laboratory University of Cambridge
On 11/18/2009 05:20 PM, Robert Watson wrote:
Has anyone else noticed that getting libdispatch to run on a new OS is the easy bit, and that figuring out the auto*/libtool/pkg-config/etc stuff is the hard bit? :-)
Uhm, I disagree. The libtool and pkg-config bits required a bit of learning curve for some people, and next time they would have quite a headstart. Mark has been great in incorporating pkg-config and libtool into libkqueue for example! And the autoconf parts (including libm and the like) are _intrinsically_ part of getting libdispatch to run on a new OS. It would be worse without autoconf, though autoconf is no global optimum (there is none), and it's definitely worth it. Hopefully, we're just a couple of patches away from running a libkqueue-based libdispatch on Linux, and of the last 40-50 patches definitely not all of them were configury fixes. In fact, I wouldn't underestimate _your_ work in getting libdispatch to run a non-BSD systems. For example the conversion of the testsuite to automake was very helpful. Just my 2 cents on "Autoconf is hard, let's go shopping" :-) Paolo
On 18 Nov 2009, at 16:53, Paolo Bonzini wrote:
On 11/18/2009 05:20 PM, Robert Watson wrote:
Has anyone else noticed that getting libdispatch to run on a new OS is the easy bit, and that figuring out the auto*/libtool/pkg-config/etc stuff is the hard bit? :-)
Uhm, I disagree. The libtool and pkg-config bits required a bit of learning curve for some people, and next time they would have quite a headstart. Mark has been great in incorporating pkg-config and libtool into libkqueue for example!
And the autoconf parts (including libm and the like) are _intrinsically_ part of getting libdispatch to run on a new OS. It would be worse without autoconf, though autoconf is no global optimum (there is none), and it's definitely worth it.
Hopefully, we're just a couple of patches away from running a libkqueue-based libdispatch on Linux, and of the last 40-50 patches definitely not all of them were configury fixes. In fact, I wouldn't underestimate _your_ work in getting libdispatch to run a non-BSD systems. For example the conversion of the testsuite to automake was very helpful.
Just my 2 cents on "Autoconf is hard, let's go shopping" :-)
Well, my comment was meant at least partly in jest with a dash of cynicism :-). I selected autotools as the portability/build framework because it seemed to be the only realistic option, given the variables: lots of OS-specific behavior in libdispatch, and a desire for significant portability. The general hope for build systems is that you invest up-front and then pay minimal costs going forward once the framework is right, and I hope that will also be the case for libdispatch. I'm not convinced that this, as my second auto*/libtool project, was necessarily easier than my first one (OpenBSM), although I think I'm getting a bit better at it. While a lot of strength comes out of configure.ac's integration with shell scripting, it also means there's quite weak syntax checking and it can take a long time to find simple bugs that a language with stronger typing would catch easily. On the topic of auto* feature/help requests: (1) Is there a better way to do the MLINKS-like symlink creation in man/Makefile.am? In the BSD make framework, you use the MLINKS variable to declare a set of additional names for man pages, which at install-time result in symlinks. It would be nice if automake had a similar primitive, which created symlinks where available and copies otherwise, and in particular if the deinstall target knew how to remove them. Right now I'm using install-data-hook, probably poorly. (2) Makefile.darwin runs all the test parts under a harness, and then collects and summarizes the results. There's a bit of non-portability in the harness still to address (as far as I'm aware, Mac OS X is the only system that has the posix_spawn flags required), but also I'd like to work from a potted example of how to hook up the test parts to the test support described in the automake documentation. Is there such a thing around to look at, or can I interest some hands in doing this? Robert
On 11/18/2009 06:17 PM, Robert N. M. Watson wrote:
While a lot of strength comes out of configure.ac's integration with shell scripting, it also means there's quite weak syntax checking and it can take a long time to find simple bugs that a language with stronger typing would catch easily.
In general, the least you rely on shell scripting in configure.ac (and push that out to other self-contained macros), the least problems you're going to have. In other words, write configure.ac files as declaratively as possible. In principle, with Autoconf you should be able to shuffle your tests around completely (though that requires care in writing the macros of course).
(1) Is there a better way to do the MLINKS-like symlink creation in man/Makefile.am? In the BSD make framework, you use the MLINKS variable to declare a set of additional names for man pages, which at install-time result in symlinks. It would be nice if automake had a similar primitive, which created symlinks where available and copies otherwise, and in particular if the deinstall target knew how to remove them. Right now I'm using install-data-hook, probably poorly.
I don't think there is one.
(2) Makefile.darwin runs all the test parts under a harness, and then collects and summarizes the results. There's a bit of non-portability in the harness still to address (as far as I'm aware, Mac OS X is the only system that has the posix_spawn flags required), but also I'd like to work from a potted example of how to hook up the test parts to the test support described in the automake documentation. Is there such a thing around to look at, or can I interest some hands in doing this?
I would switch to autotest if you want to use your own harness instead of Automake's embedded one. Paolo
On the topic of auto* feature/help requests:
(1) Is there a better way to do the MLINKS-like symlink creation in man/Makefile.am? In the BSD make framework, you use the MLINKS variable to declare a set of additional names for man pages, which at install-time result in symlinks. It would be nice if automake had a similar primitive, which created symlinks where available and copies otherwise, and in particular if the deinstall target knew how to remove them. Right now I'm using install-data-hook, probably poorly.
In heimdal we solved this by parsing the mdoc pages [1] [2] and make appropriate links from this information, scary, but very useful since people don't remember to update MLINKS. However, part of the problem is people don't care to update mdoc pages either.
(2) Makefile.darwin runs all the test parts under a harness, and then collects and summarizes the results. There's a bit of non-portability in the harness still to address (as far as I'm aware, Mac OS X is the only system that has the posix_spawn flags required), but also I'd like to work from a potted example of how to hook up the test parts to the test support described in the automake documentation. Is there such a thing around to look at, or can I interest some hands in doing this?
Using automake test framework is trivial. TESTS = test-app script check_PROGRAMS = test-app Return 0 for success, 77 for test does not apply. Heimdal uses a lot of these tests [3] [4]. If you want to run the test application/scripts under a specific environment, you can set TESTS_ENVIRONMENT (check check-valgrind in [5]). maybe-valgrind checks that the app is really a app generate from libfool and not a shell script, finding memory leaks/corruption in /bin/sh is no sport (make make execution so much slower). Love [1] sed -n -e '/SYNOPSIS/q;/DESCRIPTION/q;s/^\.Nm \([^ ]*\).*/\1/p' $srcdir/$f [2] http://github.com/heimdal/heimdal/blob/master/cf/install-catman.sh [3] http://github.com/heimdal/heimdal/blob/master/lib/krb5/Makefile.am [4] http://github.com/heimdal/heimdal/blob/master/tests/kdc/Makefile.am [5] http://github.com/heimdal/heimdal/blob/master/cf/Makefile.am.common
participants (5)
-
Love Hörnquist Åstrand
-
Mario Schwalbe
-
Paolo Bonzini
-
Robert N. M. Watson
-
Robert Watson