Hardening flags

[Julien ÉLIE]

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:
   https://inn.eyrie.org/trac/changeset/9720/

"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
fail.


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/storage/libstorage.la 
/home/iulius/work/inn/trunk/history/libinnhist.la 
/home/iulius/work/inn/trunk/storage/libstorage.la 
/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/storage/.libs/libstorage.a 
/home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz


Still an open bug (from 2008):
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508658

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 
practice"!

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)