Use libgenders.a when compiling with --enable-static-modules

[GoogleCodeExporter]

When I compile pdsh-31 (and earlier) on my Solaris 10 host, it appears that 
while the modules a statically linked, the pdsh binary is still dependent on 
the libgenders.so.  If pdsh could be compiled to only depend on the usual 
Solaris shared libraries, the binary could be more "mobile".

Original issue reported on code.google.com by chris.da...@gmail.com on 21 Feb 2014 at 4:57

[GoogleCodeExporter]

Yes, unfortunately the static-modules literally means just that, modules will 
be built statically. Every other shared library will be linked dynamically, 
i.e. the binary itself will not be built statically. 

Unfortunately, I don't have much time to look at this now, but would be happy 
to accept a patch. Or I can put this on the todo list.

One thing you could try is going through your local copy and changing the 
Makefile directly in src/modules to link with libgenders.a instead of 
-lgenders...

Original comment by mark.gro...@gmail.com on 24 Feb 2014 at 2:48

• Changed state: Accepted

[GoogleCodeExporter]

I was able to get pdsh-2.31 to compile where pdsh links with the static 
libgenders.a library, but not being a developer by trade, I'm not sure how to 
do so properly.

First, I built genders-1.20 with no shared library (--disable-shared).  At that 
point, I received a missing symbols error for libgenders while linking all of 
the object files into pdsh.inst and pdsh.  Therefore, I modified 
pdsh-2.31/src/pdsh/Makefile as follows.  This is a manually cludge, but I don't 
know the proper way to use only the library file when the shared library file 
exists.  The linker option, -Bstatic, didn't seem to work.  Plus, I know where 
or what to add to update the linker command(s) when the user specifies 
'--static-modules' to configure.

$ diff src/pdsh/Makefile-original src/pdsh/Makefile          
448c448
<       $(LINK) $(pdsh_LDFLAGS) $(pdsh_OBJECTS) $(pdsh_LDADD) $(LIBS)
---
>       $(LINK) $(pdsh_LDFLAGS) $(pdsh_OBJECTS) $(pdsh_LDADD) $(LIBS) -lgenders
451c451
<       $(LINK) $(pdsh_inst_LDFLAGS) $(pdsh_inst_OBJECTS) $(pdsh_inst_LDADD) 
$(LIBS)
---
>       $(LINK) $(pdsh_inst_LDFLAGS) $(pdsh_inst_OBJECTS) $(pdsh_inst_LDADD) 
$(LIBS) -lgenders

Original comment by chris.da...@gmail.com on 27 Apr 2015 at 5:20

[GoogleCodeExporter]

Unfortunately, linking the pdsh binary with genders directly isn't going to 
work in general, because the build will fail if libgenders isn't available.

I'm actually suprised that the "libmods.a" static library doesn't include the 
libgenders.a static library. Can  you paste or attach the errors you were 
getting before you manually edited the pdsh Makefile above?

Original comment by mark.gro...@gmail.com on 27 Apr 2015 at 10:57

[GoogleCodeExporter]

If you are able to run `./bootstrap` and configure --enable-static-modules, the 
attached patch might help.. It adds `-all-static` to the pdsh build line, 
building a completely static pdsh executable (on my Linux system). (I do get a 
lot of scary warnings tho)  :-)

We could also try just adding -all-static to the libmods.la build, or maybe 
even just building with

 EXTRA_LDFLAGS=-all-static ./configure ....

Though when I tried something like that configure complained that it couldn't 
find a working poll(2) or select(2) implementation, so the latter may be a bit 
heavy handed...

Original comment by mark.gro...@gmail.com on 27 Apr 2015 at 11:28

Attachments:

• p

[GoogleCodeExporter]

If I compile libgenders with '--disable-shared', the pdsh compile returns the 
typical missing symbols errors when linking everything together for pdsh.inst 
and pdsh.

/usr/bin/cc -fast -I/home/chris/development/install/build_pdsh_all/include 
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o pdsh.inst main.o dsh.o mod.o rcmd.o 
opt.o privsep.o pcp_server.o pcp_client.o testcase.o wcoll.o cbuf.o xpopen.o 
config.o  -L/home/chris/development/install/build_pdsh_all/lib 
../../src/modules/.libs/libmods.a ../../src/common/.libs/libcommon.a -lpthread 
-lsocket -lnsl
Undefined                       first referenced
 symbol                             in file
genders_errormsg                    ../../src/modules/.libs/libmods.a(genders.o)
genders_nodelist_create             ../../src/modules/.libs/libmods.a(genders.o)
genders_handle_destroy              ../../src/modules/.libs/libmods.a(genders.o)
genders_index_attrvals              ../../src/modules/.libs/libmods.a(genders.o)
genders_getmaxvallen                ../../src/modules/.libs/libmods.a(genders.o)
genders_testattr                    ../../src/modules/.libs/libmods.a(genders.o)
genders_getnodes                    ../../src/modules/.libs/libmods.a(genders.o)
genders_query                       ../../src/modules/.libs/libmods.a(genders.o)
genders_errnum                      ../../src/modules/.libs/libmods.a(genders.o)
genders_load_data                   ../../src/modules/.libs/libmods.a(genders.o)
genders_handle_create               ../../src/modules/.libs/libmods.a(genders.o)
genders_nodelist_destroy            ../../src/modules/.libs/libmods.a(genders.o)
ld: fatal: symbol referencing errors. No output written to pdsh.inst

After which, I make the changes in #2 and run 'make'.  Obviously, the linker is 
finding the static library in the end.  If I build libgenders with the shared 
libs, the pdsh build uses the shared lib for genders, even if I use '-Bstatic' 
or '-static' with $CFLAGS.

By the way, I am building this on Solaris 10/SPARC with the Sun compiler, 
though the stock GCC works similarly. I'm not sure off-hand about Linux, but 
nowadays no Solaris binary is purely static.  Not even /sbin/sh is purely 
static anymore.

While I couldn't figure out how to use 'patch' to apply the diffs, I did so 
manually.  The problem is bootstrap used the stock GNU m4 and there were errors 
(below).

$ ./bootstrap 
./bootstrap: libtoolize: not found
running aclocal  ... 
/opt/sfw/share/aclocal/progtest.m4:13: warning: underquoted definition of 
AM_PATH_PROG_WITH_TEST
/opt/sfw/share/aclocal/progtest.m4:13:   run info Automake 'Extending aclocal'
/opt/sfw/share/aclocal/progtest.m4:13:   or see 
http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal
autom4te: need GNU m4 1.4 or later: /opt/sfw/bin/m4
aclocal: error: autom4te failed with exit status: 1
running libtoolize ...
./bootstrap: libtoolize: not found
running autoheader ... 
autom4te: need GNU m4 1.4 or later: /opt/sfw/bin/m4
autoheader: '/opt/sfw/bin/autom4te' failed with exit status: 1
running automake --add-missing ... 
autom4te: need GNU m4 1.4 or later: /opt/sfw/bin/m4
automake: error: /opt/sfw/bin/autoconf failed with exit status: 1
running autoconf ... 
autom4te: need GNU m4 1.4 or later: /opt/sfw/bin/m4

I don't think this part is worth resolving. Or at least, it is a dead end for 
me. I know statically linking all but the core system libraries is only useful 
to a handful of people. I wanted to know I did get libgenders linked 
statically.  If you see it worth pursuing, attached a patched tarball of the 
source, and I will attempt it on my system.  It looks like continued 
development isn't a priority, which isn't an issue for me as well.  pdsh does 
all I need.

Original comment by chris.da...@gmail.com on 28 Apr 2015 at 12:12