Hardening flags

Julien ÉLIE julien at trigofacile.com
Fri Nov 13 10:33:31 UTC 2020

Hi all,

> A remaining issue is a build with "--with-pic=no".

I would finally just suggest to disable the generation of shared 
libraries when PIC mode is disabled.
--with-pic=no -> call to AC_DISABLE_SHARED

I'm also wondering whether a --with-pie configure option wouldn't be 
useful to have.  It would be on by default, and would permit to easily 
disable a PIE build when needed (for instance in architectures that do 
not support it correctly).

> ovdb does not build:
> /home/iulius/work/gcc/gcc-10.1.0/bin/gcc -fPIE -pie -o ovdb_init 
> ovdb_init.o  /home/iulius/work/inn/trunk/history/.libs/libinnhist.a 
> /home/iulius/work/inn/trunk/storage/.libs/libstorage.a 
> /home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz
> /home/iulius/work/inn/trunk/storage/.libs/libstorage.a(expire.o): dans 
> la fonction « OVhisthasmsgid »:
> /home/iulius/work/inn/trunk/storage/expire.c:804: référence indéfinie 
> vers « HISlookup »
> I'll go on fixing that tomorrow.

I believe it is the same sort of issue we once had:

"Backend commands (such as nntpget) linked with both history
and storage libraries list $(LIBSTORAGE) in the link line twice.
This isn't a mistake; there are some unfortunate circular
dependencies that require listing $(LIBSTORAGE) both before
and after $(LIBINNHIST) in the link line or static linking will

This time, it happens to frontends (ovdb) and we have libtool...
I've seen that a special flag --preserve-dup-deps can be used.  But 
unfortunately, it does not work (stripping the duplicate libstorage.la):

../libtool --preserve-dup-deps --mode=link 
/home/iulius/work/gcc/gcc-10.1.0/bin/gcc  -o ovdb_monitor ovdb_monitor.o 
/home/iulius/work/inn/trunk/lib/libinn.la  -ldb -lz

libtool: link: /home/iulius/work/gcc/gcc-10.1.0/bin/gcc -o ovdb_monitor 
ovdb_monitor.o  /home/iulius/work/inn/trunk/history/.libs/libinnhist.a 
/home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz

Still an open bug (from 2008):

Hopefully a working patch is given.
=> Just uncommenting the new_libs assignment line, and remove the rest 
of the for loop.  Well, we are in the case of the "very few problems in 

In support/ltmain.sh:

           for deplib in $tmp_libs; do
             # FIXME: Pedantically, this is the right thing to do, so
             #        that some nasty dependency loop isn't accidentally
             #        broken:
             #new_libs="$deplib $new_libs"
             # Pragmatically, this seems to cause very few problems in
             # practice:

It fixes the build with static libraries (which has not been working 
since a few releases).

Julien ÉLIE

« – Nous parlerons quand l'interprète dormira. [Bong !]
   – Il dort. On peut parler. » (Astérix)

More information about the inn-workers mailing list