On Mon, Jan 17, 2011 at 03:10:27PM -0800, Ian Lance Taylor wrote: > Bob Rossi <bob@xxxxxxxxxx> writes: > > > On Sat, Jan 15, 2011 at 08:09:16PM -0800, Ian Lance Taylor wrote: > >> However, what you describe is safe on current versions of GNU/Linux. It > >> is safe if 1) your linker supports the --eh-frame-hdr option (binutils > >> 2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc > >> was configured to be aware of both these facts. These facts have been > >> true for at least five years on GNU/Linux systems. > >> > >> What is the range of configurations you have to consider? > > > > Well, essentially any configuration that someone asks to run the > > software on. > > > > Regarding points 1, 2, and 3. Do those have to be true at link time > > (when i'm building the executable on the machines I control) > > or at load time (when the user goes to run the executable on the > > machines they control)? > > Unless you are linking statically, the dl_iterate_phdr function has to > be available at runtime, in libc.so.6. Every other aspect is only > required at link time, on a machine you control. You are probably safe > enough on GNU/Linux in practice, the question you'll have to consider is > whether you have to run on non-GNU/Linux systems. Thanks for the help so far! So, we've described how static linking isn't always safe for libgcc. I've also described how I have shared objectcs that I load at run time. These libraries depend on libgcc as well. I build the software on an old linux machine, with a new version of GCC. So I've got a relative new version of libgcc. I'm thinking about distributing my libgcc_so using the linker rpath solution, using ORIGIN to make it relative to the executable. Does it make sense to distribute my newer version of libgcc with my executables in this way? Thanks, Bob
