"Spacen Jasset" wrote > Steven Schveighoffer wrote: >> "Spacen Jasset" wrote >>> Steven Schveighoffer wrote: >>>> You may have to statically link (which, of course, is not officially >>>> supported by glibc, for very stupid reasons). >>> I am not sure that the reasons are "stupid". It is similar, for example >>> to kernel32.dll on windows, which you cannot link to statically *at all* >>> libc is a comparable interface in that it calls into the kernel. >> >> The reasons are not so concrete. It's more a matter of opinion than >> requirement. >> >> For example, see this web page: >> http://people.redhat.com/drepper/no_static_linking.html >> >> I ran into this when trying to get busybox working. It took me a while >> to figure out, but I ended up using a dynamic glibc. Apparently, there >> are bugs in glibc with static linking that the developers refuse to fix >> because "static linking glibc isn't a valid requirement." >> >> Yet some very important programs are statically linked. For example, >> ldconfig and nash (Red Hat's system loader shell). It just seems stupid >> to me when they preach that you should *always* dynamically link, yet >> there are cases where they found it more suitable to statically link. >> >> Just my opinion. >> >> -Steve > It is the way it is at the end of the day. I don't consider it too > unreasonable to require dynamic linking for things such as glibc. (again, > just like kernel32.dll and user32.dll on windows)
Sure, I agree with you there. No matter how much whoever complains about this, it's not going to be addressed, so complaining generally isn't very productive ;) I don't think it's unreasonable to require glibc to be dynamic, but again, you have issues that come up which might be solvable if glibc supported static linking. It's all fine in theory until you start encountering reality. > As for bugs in glibc preventing static linking I can't comment except to > say that the the kernel apis do sometimes change and I have read that > static linking will case crashes, which it does. It appears they don't > want to maintain static compatibility in this way. However, if you do > build glibc from source there is a configurable option to provide > compatability wrappers, I noticed this when building a cross compiler. I don't think this is the reason for the bugs. I think they are just design flaws which the developers consider moot because nobody should be statically linking in their opinion. > For us Linux DMD users a bug should be raised against dmd so that Walter > will hopefully compile against an older glibc on future releases. As long as it doesn't cause weird problems. I have had weird stuff happen when you are running an older app against a newer lib (specifically, the program exited silently). Plus, I think the OP essentially was looking to run programs that DMD compiled, not necessarily running DMD itself. -Steve
