[PATCH] missing kqueue libs in testing/Makefile.am
Hi, added libkqueue library variable to testing/Makefile.am. ciao, Mario Index: testing/Makefile.am =================================================================== --- testing/Makefile.am (Revision 165) +++ testing/Makefile.am (Arbeitskopie) @@ -81,4 +81,5 @@ LDADD=libtest.la ../src/libdispatch.la CFLAGS=-Wall $(MARCH_FLAGS) $(CBLOCKS_FLAGS) CXXFLAGS=-Wall $(MARCH_FLAGS) $(CXXBLOCKS_FLAGS) +LIBS=$(KQUEUE_LIBS)
On Mon, 16 Nov 2009, Mario Schwalbe wrote:
added libkqueue library variable to testing/Makefile.am.
In general, the testing tools don't directly depend on kqueue (with the exception of dispatch_cffd, which is not portable off of Mac OS X). Normally, libdispatch should depend on libkqueue, meaning that applications linked aginst libdispatch shouldn't need their own dependency declared unless they might use libkqueue but no libdispatch. If you run ldd on libdispatch as built on your system, does it not list libkqueue as a dependency in the same way it lists libpthread, etc? Robert N M Watson Computer Laboratory University of Cambridge
ciao, Mario
Index: testing/Makefile.am =================================================================== --- testing/Makefile.am (Revision 165) +++ testing/Makefile.am (Arbeitskopie) @@ -81,4 +81,5 @@ LDADD=libtest.la ../src/libdispatch.la CFLAGS=-Wall $(MARCH_FLAGS) $(CBLOCKS_FLAGS) CXXFLAGS=-Wall $(MARCH_FLAGS) $(CXXBLOCKS_FLAGS) +LIBS=$(KQUEUE_LIBS)
_______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Hi, Robert Watson schrieb:
On Mon, 16 Nov 2009, Mario Schwalbe wrote:
added libkqueue library variable to testing/Makefile.am. In general, the testing tools don't directly depend on kqueue (with the exception of dispatch_cffd, which is not portable off of Mac OS X). Normally, libdispatch should depend on libkqueue, meaning that applications linked aginst libdispatch shouldn't need their own dependency declared unless they might use libkqueue but no libdispatch. If you run ldd on libdispatch as built on your system, does it not list libkqueue as a dependency in the same way it lists libpthread, etc?
Indeed, it does: # ldd libdispatch.so linux-vdso.so.1 => (0x00007fff6fde6000) libkqueue.so => not found librt.so.1 => /lib/librt.so.1 (0x00007fb4d09bd000) libc.so.6 => /lib/libc.so.6 (0x00007fb4d064d000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007fb4d0431000) /lib64/ld-linux-x86-64.so.2 (0x00007fb4d0e05000) But $(KQUEUE_LIBS) does not only contain -lkqueue but also -L<path_to_libkqueue> which I need to link the application, since defaults of /lib,/usr/lib,... do not suffice, because I installed to a non-standard prefix. ciao, Mario
On 11/17/2009 06:55 AM, Mario Schwalbe wrote:
Indeed, it does: # ldd libdispatch.so linux-vdso.so.1 => (0x00007fff6fde6000) libkqueue.so => not found
You should add -Wl,-rpath,/path/to/libkqueue/libdir or similar to LDFLAGS at configure time when building libdispatch. Or, of course, add the directory to the default loader search path in ld.so.conf. Peter -- Peter O'Gorman http://pogma.com
Hi, Peter O'Gorman schrieb:
You should add -Wl,-rpath,/path/to/libkqueue/libdir or similar to LDFLAGS at configure time when building libdispatch. Or, of course, add the directory to the default loader search path in ld.so.conf.
Doesn't -L/path/to/libkqueue/libdir work as well? Of course, I could also use LDFLAGS, since I only need the -L-part of $(KQUEUE_LIBS). The -l-part is superfluous, as Robert pointed out. So which variable is better? ciao, Mario Index: testing/Makefile.am =================================================================== --- testing/Makefile.am (Revision 166) +++ testing/Makefile.am (Arbeitskopie) @@ -81,4 +81,5 @@ LDADD=libtest.la ../src/libdispatch.la CFLAGS=-Wall $(MARCH_FLAGS) $(CBLOCKS_FLAGS) CXXFLAGS=-Wall $(MARCH_FLAGS) $(CXXBLOCKS_FLAGS) +LDFLAGS=$(KQUEUE_LIBS)
On Tue, 17 Nov 2009, Mario Schwalbe wrote:
Peter O'Gorman schrieb:
You should add -Wl,-rpath,/path/to/libkqueue/libdir or similar to LDFLAGS at configure time when building libdispatch. Or, of course, add the directory to the default loader search path in ld.so.conf.
Doesn't -L/path/to/libkqueue/libdir work as well? Of course, I could also use LDFLAGS, since I only need the -L-part of $(KQUEUE_LIBS). The -l-part is superfluous, as Robert pointed out.
So which variable is better?
But this still leaves you with a binary that depends on a library in a non-standard prefix -- I'm not sure that "fixing" the binary to link when it can't run is an improvement? Having it added explicitly to the configure command line makes it clear to the user/administrator/rebundler that the alternate library path run-time property that will also be required to use the binary later. Robert N M Watson Computer Laboratory University of Cambridge
Hi, Peter O'Gorman schrieb:
You should add -Wl,-rpath,/path/to/libkqueue/libdir or similar to LDFLAGS at configure time when building libdispatch. Or, of course, add the directory to the default loader search path in ld.so.conf.
Please ignore my previous mail. I finally realized that you meant the library itself, not the whole project. Using -Wl,-rpath,/libkqueuedir is a better solution then and adding libdispatch_la_LDFLAGS=-Wl,-rpath,/libkqueuedir works, but how do we extract the path from the $(KQUEUE_LIBS)? I tried some make filter and replace magic but it's difficult as the replacement text contains commas. ciao, Mario
On 11/17/2009 06:09 PM, Mario Schwalbe wrote:
Using -Wl,-rpath,/libkqueuedir is a better solution then and adding libdispatch_la_LDFLAGS=-Wl,-rpath,/libkqueuedir works, but how do we extract the path from the $(KQUEUE_LIBS)?
You need to do that manually, or change libkqueue to use libtool. That would automagically fix the problem too. Paolo
Paolo Bonzini wrote:
On 11/17/2009 06:09 PM, Mario Schwalbe wrote:
Using -Wl,-rpath,/libkqueuedir is a better solution then and adding libdispatch_la_LDFLAGS=-Wl,-rpath,/libkqueuedir works, but how do we extract the path from the $(KQUEUE_LIBS)?
You need to do that manually, or change libkqueue to use libtool. That would automagically fix the problem too.
Mario, I just committed r100 which generates and installs a Libtool-compatible libkqueue.la file into $LIBDIR. This should simplify the handling of inter-library dependencies, as well as make it easier to use a non-standard installation path. I'm working on integrating libkqueue.la with libdispatch, and will send a patch shortly. Regards, - Mark P.S. Here is a transcript of my testing using libkqueue.la: $ ./configure --prefix=/tmp/bar checking operating system type.. linux checking for a BSD-compatible install.. /usr/bin/install checking for sys/epoll.h.. yes checking for sys/inotify.h.. yes checking for sys/signalfd.h.. yes checking for sys/timerfd.h.. yes checking for sys/eventfd.h.. yes Creating libkqueue.pc Creating libkqueue.la Creating rpm.spec Creating config.h Creating config.mk $ make cc -fPIC -I./include -I./src/common -Wall -Werror -c src/common/*.c src/linux/proc.c src/linux/signal.c src/linux/socket.c src/linux/timer.c src/linux/user.c src/linux/vnode.c ar rcs libkqueue.a *.o gcc -shared -Wl,-soname,libkqueue.so -o libkqueue.so *.o $ make install /usr/bin/install -d -m 755 /tmp/bar/include/kqueue/sys /usr/bin/install -m 644 include/sys/event.h /tmp/bar/include/kqueue/sys/event.h /usr/bin/install -d -m 755 /tmp/bar/lib /usr/bin/install -m 644 libkqueue.so libkqueue.la libkqueue.a /tmp/bar/lib /usr/bin/install -d -m 755 /tmp/bar/lib/pkgconfig /usr/bin/install -m 644 libkqueue.pc /tmp/bar/lib/pkgconfig /usr/bin/install -d -m 755 /tmp/bar/share/man/man2 /usr/bin/install -m 644 kqueue.2 /tmp/bar/share/man/man2/kqueue.2 /usr/bin/install -m 644 kqueue.2 /tmp/bar/share/man/man2/kevent.2 $ cd test $ ./configure checking operating system type.. linux checking for a BSD-compatible install.. /usr/bin/install checking for sys/event.h.. no checking ../include/sys/event.h for EV_DISPATCH.. yes checking ../include/sys/event.h for EV_RECEIPT.. yes checking ../include/sys/event.h for NOTE_TRUNCATE.. no checking ../include/sys/event.h for EVFILT_TIMER.. yes checking ../include/sys/event.h for EVFILT_USER.. yes Creating config.h Creating config.mk $ gcc -I/tmp/bar/include/kqueue -c *.c $ libtool --mode=link gcc -g -O0 -o a.out *.o /tmp/bar/lib/libkqueue.la libtool: link: gcc -g -O0 -o a.out main.o proc.o read.o signal.o timer.o user.o vnode.o /tmp/bar/lib/libkqueue.so -L/tmp/bar/lib -lpthread -lrt -Wl,-rpath -Wl,/tmp/bar/lib -Wl,-rpath -Wl,/tmp/bar/lib $ ldd a.out linux-vdso.so.1 => (0x00007fff63fff000) libkqueue.so => /tmp/bar/lib/libkqueue.so (0x00007f7f5bafa000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f7f5b8de000) librt.so.1 => /lib/librt.so.1 (0x00007f7f5b6d6000) libc.so.6 => /lib/libc.so.6 (0x00007f7f5b364000) /lib64/ld-linux-x86-64.so.2 (0x00007f7f5bd03000)
Robert Watson wrote:
On Mon, 16 Nov 2009, Mario Schwalbe wrote:
added libkqueue library variable to testing/Makefile.am.
In general, the testing tools don't directly depend on kqueue (with the exception of dispatch_cffd, which is not portable off of Mac OS X). Normally, libdispatch should depend on libkqueue, meaning that applications linked aginst libdispatch shouldn't need their own dependency declared unless they might use libkqueue but no libdispatch.
I believe that libkqueue r101 solves this problem by changing the output of `pkg-config --libs` from this: -L${libdir} -lkqueue to this: ${libdir}/libkqueue.la This allows libtool to generate a libdispatch.la that contains all of the dependencies for libkqueue. Here is an example of what it generates: # Libraries that this one depends upon. dependency_libs=' /tmp/bar/lib/libkqueue.la -L/tmp/bar/lib -lpthread -lrt' Note that in order for pkg-config to find the libkqueue in /tmp/bar, the PKG_CONFIG_PATH environment variable must be set like this: PKG_CONFIG_PATH=/tmp/bar/lib/pkgconfig ./configure Let me know if this works for you. Thanks, - Mark
On 11/18/2009 05:26 AM, Mark Heily wrote:
I believe that libkqueue r101 solves this problem by changing the output of `pkg-config --libs` from this:
-L${libdir} -lkqueue
to this:
${libdir}/libkqueue.la
Does it actually make a difference? libtool should look for the .la file anyway, and now you've forced every libkqueue.pc client to use libtool... :-) Paolo
Paolo Bonzini wrote:
On 11/18/2009 05:26 AM, Mark Heily wrote:
I believe that libkqueue r101 solves this problem by changing the output of `pkg-config --libs` from this:
-L${libdir} -lkqueue
to this:
${libdir}/libkqueue.la
Does it actually make a difference? libtool should look for the .la file anyway, and now you've forced every libkqueue.pc client to use libtool... :-)
Paolo
Good question. The description of PKG_CHECK_MODULES Autoconf macro in the pkg-config manpage doesn't say anything about libtool [1]. Likewise, the libtool documentation doesn't say anything about pkg-config. I assumed that adding the .la file to the .pc file was the only way to get them to work together. However, you are correct that Libtool is smart enough to look for the .la file and use it instead of the output of `pkg-config --libs`. Thanks for pointing this out, and I have committed r102 that sets the pkg-config Libs variable to: Libs: -L${libdir} -lpthread -lrt -lkqueue Regards, - Mark [1] From pkg-config(1): PKG_CHECK_MODULES(VARIABLE-PREFIX,MODULES[,ACTION-IF-FOUND,[ACTION-IF- NOT-FOUND]]) The macro PKG_CHECK_MODULES can be used in configure.ac to check whether modules exist. A typical usage would be: PKG_CHECK_MODULES([MYSTUFF], [gtk+-2.0 >= 1.3.5 libxml = 1.8.4]) This would result in MYSTUFF_LIBS and MYSTUFF_CFLAGS substitu- tion variables, set to the libs and cflags for the given module list.
Hi, Mark Heily schrieb:
I believe that libkqueue r101 solves this problem by changing the output of `pkg-config --libs` from this [...] Note that in order for pkg-config to find the libkqueue in /tmp/bar, the PKG_CONFIG_PATH environment variable must be set like this:
PKG_CONFIG_PATH=/tmp/bar/lib/pkgconfig ./configure
Let me know if this works for you.
That's what i already did. And yes, as predicted it works. Thanks a lot. ciao, Mario
participants (5)
-
Mario Schwalbe
-
Mark Heily
-
Paolo Bonzini
-
Peter O'Gorman
-
Robert Watson