Re: __syscall_error (was Re: [PATCH v4 13/15] ARC: Build Infrastructure)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, 1 Apr 2020, Vineet Gupta via Libc-alpha wrote:

> > If there's an inline function referring to this in an installed header, we 
> > can consider whether that inline function *should* be referring to it.  
> > Similarly if there's a reference in crt*.o / lib*_nonshared.a / GCC static 
> > libraries, we can consider if that reference *should* be there or if the 
> > function in question should actually be calling some function from 
> > that does the syscall there.
> The assembler macros in syscall template for generating wrappers use
> __syscall_error (sysdeps/unix/sysv/linux/arc/sysdep.h).

That's an internal header.  It might be included in code used in crt*.o / 
lib*_nonshared.a, but can't be included from any installed header, so 
can't result in references in inline functions from installed headers.

> If public Version is removed, I get errors like below:

What if you move it to GLIBC_PRIVATE?  My concern isn't that it's exported 
from the shared library, it's that it's exported at a public version.

A public version is only needed if there are references in code that might 
be statically linked into user binaries that use shared libc.  Which means 
the symbol being used in some .o or .a file that gets linked into user 
binaries in that case (crt*.o, lib*_nonshared.a).  You can examine the 
symbols used by such objects after building and installing glibc.

Joseph S. Myers

linux-snps-arc mailing list

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux