For a future release of Portable OpenSSH, it would be nice to have a ./configure option to enable the binaries produced, to be statically linked. I tried using LDFLAGS option to ./configure .... but this passes arguments to gcc not ld, this should be documented. Additionally, I feel that ./configure should --extra-inc=dir and --extra-lib=dir to add paths to compile (-I) and link lines (-L & -R). Also I noticed that -I/usr/local/include and -L/usr/local/lib -R/usr/local/lib are included in the CFLAGS and LDFLAGS when these directories do not even exist (on my system). Thanks for a great tool, Peter PS: If your wondering who all this came up: To install kde-2.1 (on solaris 8 intel) I needed to recompile nearly all of my libs to be dynamic linked - no problem - but then the next version of OpenSSH I installed does not run due to a missing run-time library path (ie no -R dir specified during linking). I fixed that, no real drama, but I like the idea of OpenSSH being statically linked and not dependant on other modules (packages). PPS: Maybe use of libtool would increase portability - just a thought, I was looking into it last week and it seems cool, but the biggy now is to learn to use AutoMake and AutoConf :-) So I can submit configure patches not just code ones :-) __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
>For a future release of Portable OpenSSH, it would be nice to have a >./configure option to enable the binaries produced, to be statically >linked.Please don't do this, static linking is evil and I really wish it wasn't supported anymore, see the following list of reasons why: Issues with static linking -------------------------- Static linking reduces the overhead when the program is started up, mainly because relocations and other start-up activities are done at compile time. However, static linking is generally discouraged. Here are some reasons : * 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. * Static linking greatly increases working set size and disk footprint. * Statically linked executables are NOT necessarily binary compatible between releases. eg. statically linked programs that use libsocket will failed if compiled on 2.5.1 or less and run on 2.6 * Running a static binary compiled on the base could cause a program to bypass some security checks when running under Trusted Solaris. This doesn't open a vulnerability but might mean a program won't get the extra privilege it was configured with. * Patches to system libaries for bug fixes and performance enhancements are not automatically picked up by the application. Consider security fixes to libc not being available to your application. * Some debugging libraries/tools will fail to work properly. eg. malloc debugging. * Localistation via setlocale(3c) / gettext(3c) is not supported when libc is statically linked. When to use static linking -------------------------- * The binary is critical to system operation when in single user-mode either for the startup of the OS or for disaster recovery. * Statically linking a private (internal) libarary is okay. Don'ts ------ * Statically link against libc * Statically link against libdl -- Darren J Moffat
>Besides.. I don't expect dynamicly linked binaries to work from Solaris >2.5.1 to Solaris 8. =) That is an unreasonable request. LibraryAcutally it isn't that unreasonable (many of our customers expect it and we work very hard to live up to it) and if you only use the published APIs it should work. In fact it is stronger than that Sun has a guarantee that it will, more details at: http://www.sun.com/software/solaris/programs/guarantee/ The other thing to note is that there are no static libraries in Solaris for 64bit and no static libraries for anything that joins Solaris after Solaris 8.>developers do break binary API between release.. Heck OpenSSL has notSun tries not to with our libraries and where we do it is often because the part of the API the user was dependant on wasn't public or we made and annoucement that it was going away. A lot of work has been done to our libraries recently to make sure the scope of stuff in them is very clearly marked and stuff that is private really is private. As long as static linking isn' the default for Solaris and libc never gets statically linked then I'm reasonably happy. -- Darren J Moffat
> But in general you are correct - esp WRT to vendor libraries. >But do thirdparty libraries need to follow this rigour or reasoning ?In theory I would say yes, but in practice probably not because most 3rd Party stuff doesn't have a "standard" location and most also don't have the concept of patching and versioning that Solaris uses so dynamically link OS libraries but static for thinks like OpenSSL libcrypto is fine as long as you know the pit falls I outlined.>PS: Is it possible to change a Solaris RunTime Library location ( ie-R >option) after the executable has been created ?In Solaris 8 yes, using crle(1). -- Darren J Moffat
>now i must ask, especially since we have someone from sun engineering >paying attention to OpenSSH (hi Darren!), just why the most beautifully >engineered kernel archetecture (solaris) does not yet have a >cryptographic-grade random device?!? the /dev/random supplied withI can't comment officially but I'm sure you won't be dissapointed in the future ;-) The /dev/random that comes with the iPlanet stuff I believe is the cryptorandd implmenation from the SUNWski package, I'm not sure of its quality but I have heard reporsts that PRNGd is better but an in kernel /dev/random (and /dev/urandom for that matter) is much more likely to give better randomness. -- Darren J Moffat
Hi, On Tue, Mar 27, 2001 at 01:19:57PM -0500, Christopher Linn wrote:> > Entropy collection and pooling is best handled by long-running processes > > (ideally the kernel) as they get many more opportunities to gather > > better quality randomness over their lifetime. > > bingo. the kernel.Yes, but not all of us have the choice - AIX, SCO, and so on need random numbers. So PRNGd is fine for systems lacking /dev/*random... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de
Gert, On Tue, Mar 27, 2001 at 08:36:28PM +0200, Gert Doering wrote:> Hi, > > On Tue, Mar 27, 2001 at 01:19:57PM -0500, Christopher Linn wrote: > > bingo. the kernel. > > Yes, but not all of us have the choice - AIX, SCO, and so on need random > numbers. So PRNGd is fine for systems lacking /dev/*random...whoooooooa! yes yes yes, i love prngd! exactly! what i was doing here was to take the opportunity to politely nudge someone from a major commercial OS vendor engineering dept about providing vendor /dev/*random. if Sun Engineering takes the lead for this in the commercial market, then the other vendors will be further behind, and more glaringly so, and perhaps all of them will get going faster. now, i would assert that if there are AIX Engineers, SCO Engineers, etc etc etc reading this list, that they might be made more aware of the need for this feature, and perhaps this will trickle-up to Management, and managers would be more motivated if they know Sun is that much ahead of them!> gert > --sincerely, chris -- Christopher Linn, <celinn at mtu.edu> | By no means shall either the CEC Staff System Administrator | or MTU be held in any way liable Center for Experimental Computation | for any opinions or conjecture I Michigan Technological University | hold to or imply to hold herein.
>Solaris: Need to move ssh and libz.soStarting from Solaris 8 libz.so is part of the core OS so it should be there on every host: montgomery$ pkginfo -l SUNWzlib PKGINST: SUNWzlib NAME: The Zip compression library CATEGORY: system ARCH: sparc VERSION: 11.8.0,REV=2000.01.08.18.12 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: The Zip compression library PSTAMP: humbolt20000108182857 INSTDATE: Apr 28 2000 17:38 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 16 installed pathnames 7 shared pathnames 7 directories 2 executables 409 blocks used (approx) /usr/include/zconf.h /usr/include/zlib.h /usr/lib/abi/abi_libz.so.1 /usr/lib/abi/sparcv9/abi_libz.so.1 /usr/lib/libz.so=./libz.so.1 /usr/lib/libz.so.1 /usr/lib/llib-lz /usr/lib/llib-lz.ln /usr/lib/sparcv9/libz.so=libz.so.1 /usr/lib/sparcv9/libz.so.1 /usr/lib/sparcv9/llib-lz.ln /usr/share/man/man3/libz.3 /usr/share/man/man3/zlib.3 -- Darren J Moffat