On Sat, 2009-06-20 at 09:23 -0700, Steven Dake wrote: > On Sat, 2009-06-20 at 14:32 +0200, Fabio M. Di Nitto wrote: > > Hi Jim, > > > > On Fri, 2009-06-19 at 19:19 +0200, Jim Meyering wrote: > > > When building from sources (master.git), against just-installed-to- > > > private hierarchy headers/libs from corosync and openais, I get this > > > failure: > > > > > > libtool: link: gcc -I/p/p/coro/include -g -O2 -O2 -ggdb3 -Wall -Wshadow > > > -Wmissin > > > g-prototypes -Wmissing-declarations -Wstrict-prototypes > > > -Wdeclaration-after-stat > > > ement -Wpointer-arith -Wwrite-strings -Wcast-align -Wbad-function-cast > > > -Wmissing > > > -format-attribute -Wformat=2 -Wformat-security -Wformat-nonliteral > > > -Wno-long-lon > > > g -Wno-strict-aliasing -o confdb2ldif confdb2ldif-confdb2ldif.o > > > -L/p/p/coro/lib > > > -lconfdb > > > /usr/bin/ld: warning: libcoroipcc.so.4, needed by > > > /p/p/coro/lib/libconfdb.so, no > > > t found (try using -rpath or -rpath-link) > > > /p/p/coro/lib/libconfdb.so: undefined reference to > > > `coroipcc_fd_...@corosync_cor > > > OIPCC_3.0' > > > /p/p/coro/lib/libconfdb.so: undefined reference to `coroipcc_dispatch_get' > > > /p/p/coro/lib/libconfdb.so: undefined reference to `coroipcc_dispatch_put' > > > /p/p/coro/lib/libconfdb.so: undefined reference to > > > `coroipcc_service_conn...@cor > > > OSYNC_COROIPCC_3.0' > > > /p/p/coro/lib/libconfdb.so: undefined reference to > > > `coroipcc_msg_send_reply_rece > > > i...@corosync_coroipcc_3.0' > > > /p/p/coro/lib/libconfdb.so: undefined reference to > > > `coroipcc_service_disconnect@ > > > COROSYNC_COROIPCC_3.0' > > > collect2: ld returned 1 exit status > > > make[3]: *** [confdb2ldif] Error 1 > > > make[3]: Leaving directory `/h/meyering/w/co/cluster/config/tools/ldap' > > > make[2]: *** [all-recursive] Error 1 > > > make[2]: Leaving directory `/h/meyering/w/co/cluster/config/tools' > > > make[1]: *** [all-recursive] Error 1 > > > make[1]: Leaving directory `/h/meyering/w/co/cluster/config' > > > make: *** [all-recursive] Error 1 > > > [Exit 2] > > > > I am able to reproduce this error, but there is something that I don't > > like about it. > > > > When installing in different prefixes, isn't the user supposed to update > > LD_LIBRARY_PATH accordingly? > > > > Once I set LD_LIBRARY_PATH to include the new prefix, this error doesn't > > show because the linker can find libcoroipcc. > > > > ldap config doesn't use any symbol from coroipcc directly, but only via > > libconfdb that is correctly linked. > > > > I don't believe that linking ldap tools with coroipcc is the right > > solution, but I am ready to be proven wrong tho. > > > > In any case, if we really need to link manually with coroipcc, can we > > use PKG_CONFIG rather than manual linking? > > > > Using the rpath-link linker option passed via gcc when the link path is > not ld.so.conf (or using all the time) would probably solve this > problem. Another option is LD_LIBRARY_PATH override during build.
Right, but I think that LD_LIBRARY_PATH is the right thing to do. libtools screams like crazy when specifying an "unusual" prefix that it needs to be in the LD_LIBRARY_PATH. > > The root of the problem is confdb links internally to coroipcc.so. This isn't a problem. It's something necessary. All corosync libs do but libccs is the first one to be built outside the corosync space and trigger the error. > The problem with rpath-link is it is not portable and only works with > gnu linkers so it is difficult to add it directly to the pkgconfig in > corosync until we sort out libtool. I don't like rpath or rpath-link. Fabio
