On 2012/11/05 13:57, Marc Espie wrote: > > This stuff is totally a moving target, it is probably going to change in > the future. > > > Note that there are very good reasons to prefer pie binaries in MOST cases, > including for 'static' binaries... > > So, as far as the chroot way goes, the most correct fix is probably > to provide ld.so along with your binaries... >
It would be good to have some guidance on what to do with these, a number of ports are affected. There are likely to be more, this is from a quick look over things using '-static' in patches or ports tree Makefiles. >specific static flavours:- archivers/gtar archivers/star misc/screen shells/tcsh net/nslint, static flavour security/shash, static flavour I presume the above just need -fno-pie / -nopie (or zap the static flavour if there's no point; nslint doesn't seem useful for example, not sure about shash). gtar/star/screen/tcsh are obviously intended for a recovery environment and I think should not require ld.so. >others due to chroot:- mail/femail mail/mini_sendmail net/icinga net/nagios www/fcgi-cgi devel/fossil sysutils/nut www/cgit www/haserl www/mimetex www/squid Any suggestions? We could have an always-update package containing a copy of ld.so that installs to /var/www/usr/libexec that these depend on, but if we make further changes to ld.so requiring something new from the kernel, it's going to get out of sync. Including /var/www/usr/libexec/ld.so in base would be safer but does not seem a particularly attractive option. Note that these are currently *broken* as packaged; existing users of the packages are unlikely to see the breakage, no libc bump since PIE (and in several of these cases no dependency on libc in the whole package anyway) so there won't have been reason for pkg_add to update them. However people installing these from scratch (or forcing an update) will have problems. >some others known to use -static:- security/tempwatch security/cryptcat x11/wmii benchmarks/bonnie benchmarks/bytebench
