[Cluster-devel] [PATCH] Avoid link failure...

[Cluster-devel] [PATCH] Avoid link failure...

[Jim Meyering]

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_get at 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_connect at COR
OSYNC_COROIPCC_3.0'
/p/p/coro/lib/libconfdb.so: undefined reference to `coroipcc_msg_send_reply_rece
ive at 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]

Here's the patch:

From aa504c6bcd3835bcd67e1ce8736e21132f0c43bf Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Fri, 19 Jun 2009 19:16:52 +0200
Subject: [PATCH] Avoid build failure when building against "make-installed-to-prefix"

corosync+openais trees.  i.e., I get /usr/bin/ld: warning: \
libcoroipcc.so.4, needed by /p/p/coro/lib/libconfdb.so, not found
* config/tools/ldap/Makefile.am (confdb2ldif_LDFLAGS): Append -lcoroipcc.
---
 config/tools/ldap/Makefile.am |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/config/tools/ldap/Makefile.am b/config/tools/ldap/Makefile.am
index 1c5c4a8..30a4c32 100644
--- a/config/tools/ldap/Makefile.am
+++ b/config/tools/ldap/Makefile.am
@@ -6,4 +6,4 @@ confdb2ldif_CPPFLAGS	= -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64

 confdb2ldif_CFLAGS	= $(confdb_CFLAGS)

-confdb2ldif_LDFLAGS	= $(confdb_LIBS)
+confdb2ldif_LDFLAGS	= $(confdb_LIBS) -lcoroipcc
--
1.6.3.2.416.g04d0

[Cluster-devel] [PATCH] Avoid link failure...

[Fabio M. Di Nitto]

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_get at 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_connect at COR
> OSYNC_COROIPCC_3.0'
> /p/p/coro/lib/libconfdb.so: undefined reference to `coroipcc_msg_send_reply_rece
> ive at 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?

Thanks
Fabio

[Cluster-devel] [PATCH] Avoid link failure...

[Steven Dake]

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_get at 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_connect at COR
> > OSYNC_COROIPCC_3.0'
> > /p/p/coro/lib/libconfdb.so: undefined reference to `coroipcc_msg_send_reply_rece
> > ive at 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.

The root of the problem is confdb links internally to coroipcc.so.  When
the gnu linker finds one of these internal dependencies, it immediately
adds it internally to the list of objects to link to.  If it can't find
the object, the symbols will not be found.

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.

Regards
-steve

> Thanks
> Fabio
> 

[Cluster-devel] [PATCH] Avoid link failure...

[Fabio M. Di Nitto]

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_get at 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_connect at COR
> > > OSYNC_COROIPCC_3.0'
> > > /p/p/coro/lib/libconfdb.so: undefined reference to `coroipcc_msg_send_reply_rece
> > > ive at 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

[Cluster-devel] [PATCH] Avoid link failure...

[Jim Meyering]

Fabio M. Di Nitto wrote:
...
>> > 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.

You're right.
I should have set LD_LIBRARY_PATH.
Thanks for keeping me honest ;-)

[Cluster-devel] [PATCH] Avoid link failure...

[Fabio M. Di Nitto]

On Sun, 2009-06-21 at 10:18 +0200, Jim Meyering wrote:
> Fabio M. Di Nitto wrote:
> ...
> >> > 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.
> 
> You're right.
> I should have set LD_LIBRARY_PATH.
> Thanks for keeping me honest ;-)

I think you just pushed the wrong patch to git :)))

Fabio

PS no big deal.. it's master ;)

[Cluster-devel] [PATCH] Avoid link failure...

[Jim Meyering]

Fabio M. Di Nitto wrote:

> On Sun, 2009-06-21 at 10:18 +0200, Jim Meyering wrote:
>> Fabio M. Di Nitto wrote:
>> ...
>> >> > 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.
>>
>> You're right.
>> I should have set LD_LIBRARY_PATH.
>> Thanks for keeping me honest ;-)
>
> I think you just pushed the wrong patch to git :)))
>
> Fabio
>
> PS no big deal.. it's master ;)

Thanks for fixing it.
I've just pushed the right one (by you) to fence:

    avoid build failure: css.h: no such file

    * fence/libfence/Makefile.am (libfence_la_CFLAGS): Fix typo:
    s/css_CFLAGS/ccs_CFLAGS/