Talk:Make a backup file: Difference between revisions
→Assumes unix
Line 13:
:::: Hmm... this warrants some thought: libc is the portable (documented) interface to the unix kernel. It can hypothetically be a static library but that is extremely rare nowadays -- almost everything requires an external libc. That said, there's also the question of "which libc", and the one used at build time is probably the right answer to that question (there will be a hard coded path in the executable which references libc for almost every working program out there in unix land). Or, that's how I would like to characterize the problem. And I think this thinking routinely applies in most all chroots. --[[User:Rdm|Rdm]] 17:14, 10 November 2011 (UTC)
::::: sure, libc is dynamically linked in most cases, but only in a few cases would you access it manually with <code>dlopen</code>.--[[User:EMBee|eMBee]] 17:40, 10 November 2011 (UTC)
:::::: Ok, but one of those cases would be an interpreter which was designed to be portable across a variety of platforms. Here, you might have a core that gets you running and then everything else is done in the interpreter. That said, I can see an argument for providing special case support for libc on unix platforms. --[[User:Rdm|Rdm]] 17:53, 10 November 2011 (UTC)
| |||