Date: Sun, 23 Jun 1996 21:15:07 -0400 (EDT) From: Chuck Robey <chuckr@Glue.umd.edu> To: Andrew Herdman <andrew@why.whine.com> Cc: questions@freebsd.org Subject: Re: Creating a true static binary Message-ID: <Pine.OSF.3.91.960623210244.10774B-100000@ginger.eng.umd.edu> In-Reply-To: <Pine.BSF.3.91.960623205710.6315B-100000@why>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jun 1996, Andrew Herdman wrote: > On Sun, 23 Jun 1996, Chuck Robey wrote: > > > On Sun, 23 Jun 1996, Andrew Herdman wrote: > > > > > I've noticed that whenever I create a static binary for people, that libc > > > is never included (perhaps others as well?) in the binary. This started > > > becomming a problem when I moved up to 2.2-960501-SNAP where libc changed > > > from 2.2 to 3.0. Is there a way to have the binary include everything it > > > needs into itself so that no libraries are necessary? > > > > Realize that doing what you ask is going to create huge binaries, but I > > guess that's your lookout ... just link your program with the -static > > option (check the gcc man page). > > Yes I know the binaries will be huge, even without libc they are huge > (thanks to motif) I've tried -static with no luck, my associates who have > gotten the binaries I have created have reported that they complained > about the missing libc.so.3.0, but they didn't complain about any missing > motif libraries. The ldd command is used to scan executeables, and reports what libs they are linked to. If you compile with the -static flag in cflags, then an ldd done on the resulting executeables should give you the error that you have not created a dynamic executeable. If it does this, then you can look to a mistake that your associates have made, because you HAVE made a standalone executeable. Dynamic executables have a file 'ld.so' prepended to them, which is a smallish binary that actually handles going out and getting the libs, when the program starts up. A program linked statically doesn't have this (always at the start of the executeable). You could verify this using the nm command, doing 'nm -n <binary name>'. If it's a shared executeable, then the first symbols you'll see are dlopen, dl.... If you don't see these at the start of the nm listing (pipe it into less, it'll be huge) then, again, you can be sure you DON'T have a shared executeable. These are the best checks that come to mind. If it passes these, then you can go looking at your associate's environments, because that's causing the problem. Make SURE they're really executing your binary, not something else in the path. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+-----------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.91.960623210244.10774B-100000>