> On Thu, Jul 7, 2011 at 12:04 PM, Daniel Mack <[email protected]> wrote: > > Ok. Would it be an option then to add it? Reading the guidelines of > > this project, I'm not sure whether support for this functions are > > wanted at all because at least the implemenations found in NetBDS's > > libc is not particularily small. What's the verdict here? Can things > > be added as long as they're build conditionally? Are there any > > alternative aproaches to achive support for these functions? I'm sure > > connman is not the only program that fails to link against uClibc due > > to this. > > No opinions? So I dare to propose an implementation :) > > Attached is patch that is not yet meant for inclusion but for RFC > only. I can split it up into multiple smaller pieces once I know that > it's basically ok. > > Some parts of the patch move symbols from libc to libresolv, according > to the header files they're defined in and also to bring it in sync > with what glibc does.
I am not sure about moving symbols to libresolv, autoconf and friends should find the symbols in libc as well. > Also, I haven't done a lot of testing yet, and major parts are just > copied over from NetBSD's libc implementation and amended according to > uClibc's internals. lib*_hidden_* has to be used only if a function is reused within the same lib*.so, simply renaming libc_hidden_* is not OK (and adding it to all others is not needed). You build first without any lib*_hidden* and check with readelf -r lib*.so, lib*_hidden needs applied to all functions that show up as jump relocation. You have left some libc_hidden_* in, it does not make any sense in files that go to another lib. ns_name.c is "empty" Peter > > Please let me know what you think. > > > Thanks, > Daniel -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
