Since release 2.9p2 we were enable to compile openssh statically. The error was reladed to openbsd_compat, and more precisely to getopt function. There are some variables that were already declared inside system default libraries. We could compiled statically with changing names some variables in getopt.c file. Do you plan on fixing such a problem on your future releases? Thanks in advance, JM
a patch would speed up fixing this. can someone produce one?
What platform do you have this problem on? SCO builds static binaries just fine. UnixWare doesn't have a chance due to no libsocket.a Solaris and Linux (Caldera & RH) don't have libpam.a so there is no chance there (with PAM). Please update the OS: check box.
Solaris does actually provide a libpam.a for 32bit binaries. Solaris has no static libraries for 64bit - because static linking is evil and almost never needed by 3rd party developers. However static linking against libpam doesn't make much sense, libpam's job in life is to bring in dynamic modules. The only time you should be statically linking is when the binary is critical to system startup or recovery and can run without any external dependancies. Using PAM fails this check since the modules it needs for authentication may not be available and in a default Solaris install are in the /usr/ filesystem. I would really discourage any one from doing static linking on Solaris as the binaries are not guaranteed to be upwardly compatible if you do - static binaries could even fail when adding patches. * Static linking prevents libc_psr.so.1 from working for platform specifics. This library automatically enables dynamically linked programs from linking in platform specific versions of various library routines which are optimized for a particular platform. These include platform optimized versions of some string functions and other frequently called functions. * Patches to system libaries for bug fixes and performance enhancements are not automatically picked up by the application. * Security fixes in system libraries are not available to statically linked applications.
This doesn't warrant a severity of 'security'
For this bug to progress, someone needs to write some autoconf tests to determine which of the getopt()-related variables are exported by libc and which we have to declare for ourselves.
I believe this was fixed in 3.4, but I know it is fixed in -cvs.
Mass change of RESOLVED bugs to CLOSED