On Mon, Jul 22, 2019 at 06:31:10PM -0500, Douglas R. Reno via blfs-dev wrote:
> On Mon, Jul 22, 2019, 6:24 PM Bruce Dubbs via blfs-dev <
> [email protected]> wrote:
>
> > On 7/22/19 5:48 PM, Ken Moffat via blfs-dev wrote:
> > > It looks as if any changes for the compile breakage caused by
> > > removing SIOCGSTAMP (and perhaps other SIOCG* definitions) from
> > > <sys/socket.h> are being left for upstreams to fix, and perhaps the
> > > next glibc release will include a fix to pull in the new header.
> > >
> > > In the meantime, the seds to define SIOCGSTAMP as 0x8906 seem to do
> > > the job. I was concerned that they might be fine for x86 but could
> > > possibly be wrong for other architectures, and we know that people
> > > sometimes use our instructions e.g. for Pi, but apparently the
> > > values are not architecture-specific.
> > >
> > > Obviously, different files need to be changed to fix different
> > > programs. But to sprovide a common explanation, could we use a
> > > standard copymember, something like (omitting the markup)
> > >
> > > sed -i 's/SIOCGSTAMP/0x8906/' ... : In linux-5.1 the definition of
Well duh, in _5.2_
> > > SIOCGSTAMP was moved and is no-longer in <sys/socket.h>. Hard-coding
> > > its value enables packages which do not know about that change to
> > > continue to compile with current headers.
> > >
> > > And perhaps add a ticket "Fixes for SIOCGSTAMP breakage" to note
> > > which packages are affected (I know some are already fixed, but
> > > perhaps use the common explanation).
I've created #12304 to keep tabs on this.
Since SIOCGSTAMPS is also used (NetworkManager, qemu), perhaps a
more generic copy-member:
sed -i ... SIOCGSTAMP ... : In linux-5.2 the definitions of
SIOCGSTAMP and SIOCGSTAMPNS were moved from <sys/socket.h>
which packages have traditionally included to get them. The
sed(s) to hard-code the value(s) enables packages to compile
correctly.
> >
> > Another workaround for the 5.2 and later kernels would be to modify
> > /usr/include/linux/sockios.h
> >
> > sed -i '/sockios.h>/a#include asm-generic/sockios.h' \
> > /usr/include/linux/sockios.h
> >
> > That included file is only 14 lines long:
> >
> > /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > #ifndef __ASM_GENERIC_SOCKIOS_H
> > #define __ASM_GENERIC_SOCKIOS_H
> >
> > /* Socket-level I/O control calls. */
> > #define FIOSETOWN 0x8901
> > #define SIOCSPGRP 0x8902
> > #define FIOGETOWN 0x8903
> > #define SIOCGPGRP 0x8904
> > #define SIOCATMARK 0x8905
> > #define SIOCGSTAMP_OLD 0x8906 /* Get stamp (timeval) */
> > #define SIOCGSTAMPNS_OLD 0x8907 /* Get stamp (timespec) */
> >
> > #endif /* __ASM_GENERIC_SOCKIOS_H */
> > ========
> >
> > I suspect that would fix things for everyone. It would make things
> > consistent with 'man 7 socket'.
> >
> > -- Bruce
> >
>
> IMO, changing the kernel headers is not a good idea. I think the solution
> of fixing the affected packages using seds for now is the best approach. So
> far I've come across Qt, Qtwebengine, and BlueZ. I'm in the process of
> building a 5.2-based system right now, and had a build of Qt running before
> I left my house.
>
> I think the man page will change soon too because, if I'm not mistaken (on
> GMail's Mobile App), that package is maintained by the kernel maintainers.
> I might be wrong there though
>
I agree that changing the kernel headers is not a good idea.
The man page will change when its maintainer (Michael Kerrisk, if my
memory is correct) gets a patch. But I see no signs that any kernel
activity, other than for a possible change to the next glibc, is
going to happen anytime soon.
ĸen
--
One pill makes you larger, And one pill makes you small.
And the ones that mother gives you, Don't do anything at all.
Go ask Alice, When she's ten feet tall.
-- Jefferson Airplane, White Rabbit
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
