binaries linking statically

[vsouvan]

configure.in contains:

#CFLAGS="$CFLAGS -I${PWD}/API/Headers -std=gnu99 -g -D_REENTRANT"
CFLAGS="$CFLAGS -I${PWD}/API/Headers -I${PWD}/API/Sources -std=gnu99 -D_REENTRANT -static -fPIC"
LDFLAGS="$LDFLAGS -L${PWD}/API/Sources"

This means all the binaries (bufr_decoder, etc, plus the examples) link statically against the library. Besides being somewhat wasteful, it makes it impossible to use 'ltrace' to trace calls from a binary into the library (which is how I noticed this).

Should be linking to the shared library, but I imagine there was a reason for this?

---

Imported from Launchpad using lp2gh.

• date created: 2010-04-23T16:04:51Z
• owner: chris-beauregard
• assignee: vanh-souvanlasy
• the launchpad url was https://bugs.launchpad.net/bugs/569075

[vsouvan]

(by vanh-souvanlasy)
The "-static" flag was added for making binary package without dependency on the shared library which have to be installed in "/usr". To simplify installation.
But this seems to be causing problems in the "configure" stage on systems that don't have the
package "glibc-static".
Therefore, the "-static" will be removed as default, as this can be added back when there is a need.

[vsouvan]

(by chris-beauregard)
Ah, but we're using autotools:

./configure --enable-static --disable-shared

You can test this by:

sh reconf
./configure --enable-static --disable-shared
make
make DESTDIR=/tmp/ecbufr install
cd /tmp/ecbufr
ldd usr/bin/bufr_decoder

... the ldd will indicate that the bufr_decoder binary has been statically linked. Additionally, there's no libecbufr.so installed. Compare that to a binary linked against a shared library which you'll see explicitly references a libecbufr.so.*