Hello. 2012/7/27 Jiří Zárevúcky <[email protected]>: > Every function that is shadowed by something in libposix would > actually have to be implemented under a different name (e.g. > __libc_memcpy()). I would like to vote against this. It would horribly pollute the namespace, it looks ugly and I am not sure how well with this would cope tools such as Doxygen or IDEs.
I would say that as much as it is possible, libc shall have no knowledge of other libraries, including libposix. >> On 27 July 2012 18:46, Martin Sucha <[email protected]> wrote: >> On the other hand, changing symbols at the object level could work even if >> the >> code contains references to posix functions e.g. in inline assembler, not >> just >> only in C code. What do you think about patching the compiled object files to >> reference correct symbols before linking, instead of using weak symbols? This has the big advantage that there would be no need to change any source code. Except libposix headers but I think that none of the solutions discussed here offer a "clean & nice" headers. I think that following could work: Leave libc as is. Libposix functions would be implemented with the posix_ prefix (no aliasing). They would call libc normally. Libposix headers would have to switch (ifdefs?) their naming whether they are included from libposix implementation (i.e. leave the posix_ prefix) or from a ported application. When included from a ported application, they would look like a standard POSIX header. No renaming macros. This allows for smooth compilation of all three components. Then, list of conflicting (overriden) functions would have to be created (probably automatically). Before linking, conflicting functions in libc would be prefixed with libc_. The same would happen in libposix (thus libposix would contain posix_memcpy calling libc_memcpy). In libposix, the posix_ prefix would then be removed. These patched object files then would be packed into a single library. The application would then be linked to this combined libc+libposix library without any (either compile time or link time) patching or other hacking. Native applications would be obviously still linked to the original libc. The disadvantage is, of course, the need to manipulate the object files (but objcopy is able to do that) and that libc (meaning the compiled code) would actually exist in two copies in the system (when considering dynamic linking). I think this is better than using preprocessor and I think this beats the aliasing because of its simplicity from writing-the-code point of view. To show that this renaming works I have created a small repository [1] where revised/ represents our libc, legacy/ represents libposix and ported/ any POSIX application. For example, look at alpha() function that takes different number of arguments in each library. make run should compile, link and run sample application that uses "legacy" API but the "revised" implementation. I would be happy to receive comments for this setup. Thanks - Vojta [1] https://github.com/vhotspur/legacy-library-reimplementation-example > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
