Is it time for a libc_fixes library yet?

Richard L. Hamilton rlhamil at smart.net
Tue Jul 11 13:55:03 UTC 2017


> On Jul 5, 2017, at 05:31, Jan Stary <hans at stare.cz> wrote:
> 
> On Jul 04 13:47:27, ken.cunningham.webuse at gmail.com wrote:
>>>> 
>>>> Perfect would be if I just wrote it into the clang code directly.
>>>> I am almost to the point where I could do that, actually. I know where it would go, I think.
>>> 
>>> I don't get it. Do you mean to mess with the compiler so that
>>> it implements itself the C functions that the system does not provide?
>> 
>> 
>> Yep :> That is just exactly what I mean.... clang does stuff like this already to help you out. Adding in various libraries, rearranging header paths, sticking in compiler and linker flags, all to suit to build system and make things work.
> 
> Does clang currently provide implementations of functions that do not exist,
> and link against them if the code calls them? Would you please shre an example?
> 
> If so, it seems to be quite a deviation from what a compiler is supposed to do.
> If I call a compiler, I expect it to compile the given code, not something that
> 
> 	1. the system does not provide
> 	2. the standard library such as libc does not provide
> 	3. the given code does not contain
> 
> Jan
> 

Depends on where it appears.  If it's added to a .o file, I'd be worried; but if it only appears when creating a full executable, then it's just another flavor of added runtime support, perhaps to bridge the difference between what the compilation environment is attempting to support in terms of source, and what the system offers in terms of needed system calls or library functions.  And in the case of providing a builtin inline implementation of  a well-known function if nothing is taking its address (so there's no worry of possible later use via a pointer-to-function), then even a .o file might have something added to it whose provenance may not be entirely obvious.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170711/4116ca32/attachment.sig>


More information about the macports-users mailing list