Bug 679938 – x11-libs/libXt - In file included from /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/x11-libs/libXt-1.1.5-r1/work/libXt-1.1.5/util/makestrs.c:29: /usr/armv7a-unknown-linux-gnueabihf/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-soft.h: No such fi

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description tt_1 2019-03-10 14:22:15 UTC]

Created attachment 568406 [details]
build log

it seems as if the build process ignores the fact that it has been started via emerge-armv7a-unknown-linux-gnueabihf, and uses hosts gcc instead of armv7a-unknown-linux-gnueabihf-gcc. Since it's been configured for armv7, it obviously can't find some arm specific header the the native gcc. 

executing this by hand: armv7a-unknown-linux-gnueabihf -DHAVE_CONFIG_H -I. -I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/x11-libs/libXt-1.1.5-r1/work/libXt-1.1.5/util -I..    -I/usr/armv7a-unknown-linux-gnueabihf/usr/include   -O2 -pipe -c -o makestrs.o /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/x11-libs/libXt-1.1.5-r1/work/libXt-1.1.5/util/makestrs.c

just as the build.log says it, gives no error. switching back to the original command of gcc -DHAVE_CONFIG_H (etc.pp.) reproduces the very same build error. 

anyone having an idea on how to fix this?

[Comment 1 tt_1 2019-03-10 14:50:09 UTC]

from the makefile: 

cat /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/x11-libs/libXt-1.1.5-r1/work/libXt-1.1.5-.arm # cat Makefile  | grep gcc

CC = armv7a-unknown-linux-gnueabihf-gcc
CC_FOR_BUILD = gcc
CPP = armv7a-unknown-linux-gnueabihf-gcc -E
LD = /usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/ld

I think it should be all armv7a?

[Comment 2 tt_1 2019-03-14 12:05:01 UTC]

This is most likely a regression, somewhere from toolchain. It works with the combination of gcc-7.3.0-r6 (host) and gcc-7.4.0 (cross-compiler), but it doesn't if gcc-8.3.0 is both host and cross-compiler.

[Comment 3 Matt Turner 2019-03-14 21:13:07 UTC]

In general I don't think we're really able to support cross compiling unless there are patches included. In this case I think you're right that it's a toolchain problem.

[Comment 4 tt_1 2019-03-14 21:34:14 UTC]

please assign to toolchain instead of closing, I just got the same error for libX11 with gcc-8.2.0-r6 as host+target compiler. 

it works fine with gcc-7.3.0-r6 as host instead, and gcc-8.2.0-r6 as cross-compiler. 

I may rename the title as soon as I find out more about the possible cause.

[Comment 5 Sergei Trofimovich (RETIRED) 2019-03-15 00:26:04 UTC]

(In reply to tt_1 from comment #4)
> please assign to toolchain instead of closing, I just got the same error for
> libX11 with gcc-8.2.0-r6 as host+target compiler. 

Why toolchain@?

> it works fine with gcc-7.3.0-r6 as host instead, and gcc-8.2.0-r6 as
> cross-compiler. 
> 
> I may rename the title as soon as I find out more about the possible cause.

> gcc -DHAVE_CONFIG_H -I. -I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/x11-libs/libXt-1.1.5-r1/work/libXt-1.1.5/util -I..    -I/usr/armv7a-unknown-linux-gnueabihf/usr/include   -O2 -pipe -c -o makestrs.o /usr/armv7a-unknown-linux-gnueabihf/tmp/portage/x11-libs/libXt-1.1.5-r1/work/libXt-1.1.5/util/makestrs.c

This looks very wrong. It uses (unqualified) host compiler and target headers. I don't expect it to work.

[Comment 6 Sergei Trofimovich (RETIRED) 2019-03-15 07:28:53 UTC]

Please also provide:
1. emerge --info
2. armv7a-unknown-linux-gnueabihf-emerge --info

[Comment 7 tt_1 2019-03-15 07:59:40 UTC]

Created attachment 569148 [details]
emerge --info from host and cross-emerge

First of all, the gcc settings from the makefile seem to be ok. From what I found out it is intentional to build makekeys with the hosts toolchain, its propably needed later on in the build for to be executed, or for running tests. 

emerge --info for gcc-8.3.0 is attached. Also going to upload some more build.logs

[Comment 8 tt_1 2019-03-15 08:10:27 UTC]

Created attachment 569150 [details]
compressed build logs

the build logs from both gcc-8.3.0 compilers

[Comment 9 tt_1 2019-03-15 08:14:38 UTC]

Created attachment 569152 [details]
the build log from gcc-7.3.0 and cross-gcc-8.2.0

the build logs are from building libXt with these compilers accoringly, I'm sorry for my terrible description :)

[Comment 10 Sergei Trofimovich (RETIRED) 2019-03-15 08:32:02 UTC]

You need to find what passes -I/usr/armv7a-unknown-linux-gnueabihf/usr/include into your build compiler ('gcc'). 'config.log' from failing build might shed some light.

[Comment 11 tt_1 2019-03-15 08:59:30 UTC]

Created attachment 569154 [details]
config logs

it seems that the value of XT_CFLAGS is kept empty with gcc-7.3.0, and isn't for gcc-8.2.0: XT_CFLAGS='-I/usr/armv7a-unknown-linux-gnueabihf/usr/include  '

no idea what happens here?

[Comment 12 Sergei Trofimovich (RETIRED) 2019-03-15 09:38:22 UTC]

(In reply to tt_1 from comment #11)
> Created attachment 569154 [details]
> config logs
> 
> it seems that the value of XT_CFLAGS is kept empty with gcc-7.3.0, and isn't
> for gcc-8.2.0: XT_CFLAGS='-I/usr/armv7a-unknown-linux-gnueabihf/usr/include 
> '

You need to look into how XT_CFLAGS is set in configure.

It's a shell script generated from configure.ac. Thus should not be hard.

Given that you have whitespace after '-I' option I think '-I' option comes from:
    pkg_cv_XT_CFLAGS=`$PKG_CONFIG --cflags "sm ice x11 xproto kbproto" 2>/dev/null`
assignment. You can also look at the config difference in meld and check what went different.

For example one ("non-working") of logs contains:
    pkg_cv_XT_CFLAGS='-I/usr/armv7a-unknown-linux-gnueabihf/usr/include '
    pkg_cv_XT_LIBS='-L/usr/armv7a-unknown-linux-gnueabihf/usr/lib -lSM -lICE -lX11 '
While another ("working") has:
    pkg_cv_GLIB_CFLAGS='-I/usr/armv7a-unknown-linux-gnueabihf/usr/include/glib-2.0 -I/usr/armv7a-unknown-linux-gnueabihf/usr/lib/glib-2.0/include'
    pkg_cv_GLIB_LIBS=-lglib-2.0
    pkg_cv_XT_CFLAGS=
    pkg_cv_XT_LIBS='-lSM -lICE -lX11'

Thus glib presence affects XT_CFLAGS. None of these flags are meant for host compiler.

util/Makefile.am uses that flag for host compiler as:
    AM_CFLAGS = $(XT_CFLAGS)

I think it can be safely removed. util/makestrs.c does not seem to use anything outside standard C libraries.

[Comment 13 tt_1 2019-03-15 14:28:47 UTC]

Created attachment 569164 [details, diff]
this is patch for libX11, a dependency of libXt

thank you so much for your guidance, I managed to get around it. libXt and libX11 cross compiled within the gcc-8.2.0 chroot 

first I'll attach the patch for libX11, a direct libXt dependency.

[Comment 14 tt_1 2019-03-15 14:30:09 UTC]

Created attachment 569166 [details, diff]
patch for libXt

and another patch for libXt

[Comment 15 tt_1 2019-03-15 16:57:59 UTC]

I think I found the root cause of this: 

On my main system, I got virtual/pkgconfig provided by dev-util/pkgconfig

On the freshly downloaded stage3, dev-util/pkgconf gets pulled in to provide virtual/pkgconfig instead. 

both have the same function, but seem to act differently when being used by the cross toolchain. 

for cross-pkgconf:
armv7a-unknown-linux-gnueabihf-pkg-config --cflags x11 xext 
-I/usr/armv7a-unknown-linux-gnueabihf/usr/include 

for cross-pkgconfig: 
armv7a-unknown-linux-gnueabihf-pkg-config --cflags x11 xext 
(throws out nothing, thus empty in the config.logs)

how did I found out? gtk+:3 failed as well, because it couldn't find some glib-binary it needs for generating something. Well, it found it in /usr/armv7a-unknown-linux-gnueabihf/usr , but thats the cross-compiled on, so it fails if executed from the host. 

gcc-7.3.0-config.log failed.log | grep X_CFLAGS

showed 
< X_CFLAGS=''
> X_CFLAGS='-I/usr/armv7a-unknown-linux-gnueabihf/usr/include '

and basically all includes had an additional include in this style with pkgconf, up to a point where even me with my shallow knowledge did scratch my head: 

> GLIB_CFLAGS='-I/usr/armv7a-unknown-linux-gnueabihf/usr/include/glib-2.0 -I/usr/armv7a-unknown-linux-gnueabihf/usr/lib/glib-2.0/include -I/usr/armv7a-unknown-linux-gnueabihf/usr/include -pthread '


how to solve the initial problem: 
emerge -Ca pkgconf
emerge -av pkgconfig --oneshot

gtk+:3 fails now for another reason. This seems related to the mayhem all the faulty includes created. libX11 and libXt emerge just fine. 

Oh, I need a little bit of guidance for where to report that bug? :-)

[Comment 16 Sergei Trofimovich (RETIRED) 2019-03-15 21:17:04 UTC]

(In reply to tt_1 from comment #15)
> I think I found the root cause of this: 

For me "root cause" of original bug is the use of target's CFLAGS against host compiler.
The below looks more like a minor deviation in default include paths.

> both have the same function, but seem to act differently when being used by
> the cross toolchain. 
> 
> for cross-pkgconf:
> armv7a-unknown-linux-gnueabihf-pkg-config --cflags x11 xext 
> -I/usr/armv7a-unknown-linux-gnueabihf/usr/include 
> 
> for cross-pkgconfig: 
> armv7a-unknown-linux-gnueabihf-pkg-config --cflags x11 xext 
> (throws out nothing, thus empty in the config.logs)

I would say this on it's own is not a bug. A minor infelicity perhaps. I like how explicit include path exposes host/target mismatch. That's a cool hack to know :)

Does pkgconf behave the same (== return /usr/include) on native system as well?

> Oh, I need a little bit of guidance for where to report that bug? :-)

The host/target CFLAGS mix bug should be reported to respective upstream bugtrackers.

For extra -I${SYSROOT}/usr/include infelicity we can ask gentoo's pkgconf maintainer (+CC floppym@). pkgconf also supports PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_SYSTEM_INCLUDE_PATH. Maybe pkgconf fails to filter out only sysroot case?

[Comment 17 tt_1 2019-03-15 21:33:59 UTC]

I don't think there is a real host/target mismatch happening? 

Because, libX11 and libXt build some tiny little helper binary, which the build script uses then later on. Since its never installed in src_install and it must be executed by the host, it should be ok to compile it for the host only, right? 

If I remember it correctly, the command of 

pkg-config --cflags x11 xext 

did show empty results for the hosts native pkg-config, provided by dev-util/pkgconf.

[Comment 18 Sergei Trofimovich (RETIRED) 2019-03-15 21:40:25 UTC]

This whole bug is about the mismatch. See #comment5 for example failed gcc command from initially attached build log.

[Comment 19 tt_1 2019-03-15 21:53:20 UTC]

From what I learned about all of this, pkgconf adds '-I/usr/armv7a-unknown-linux-gnueabihf/usr/include' every time it's queried via cross-pkg-config wrappers. It doesn't matter what the input is and what the output is. 

Or is it that it uses gcc instead of full x86_64-pc-linux-gnu-gcc that you're meaning with unqualified compiler?

[Comment 20 Sergei Trofimovich (RETIRED) 2019-03-16 10:08:05 UTC]

(In reply to tt_1 from comment #19)
> From what I learned about all of this, pkgconf adds
> '-I/usr/armv7a-unknown-linux-gnueabihf/usr/include' every time it's queried
> via cross-pkg-config wrappers. It doesn't matter what the input is and what
> the output is.

If you look at pkg-config detected in config.log you will get
    ac_cv_path_PKG_CONFIG=/usr/bin/armv7a-unknown-linux-gnueabihf-pkg-config
This tool returns arguments suitable for 'armv7a-unknown-linux-gnueabihf-gcc'.

Build system tries to pass '$(XT_CFLAGS)' to both 'gcc' and 'armv7a-unknown-linux-gnueabihf-gcc'. 'armv7a-unknown-linux-gnueabihf-gcc' is used to cross-compile the library itself. 'gcc' (which is not 'armv7a-unknown-linux-gnueabihf-gcc') is used to build a native tool 'makestrs'. Passing the wrong flags is an effect of the following Makefile setup:

  util/Makefile.am
    AM_CFLAGS = $(XT_CFLAGS)

If the libraries passed to pkg-config were installed to non-standard locations (say, ${SYSROOT}/usr/include/${library}) then the build would fail for both 'pkg-config' and 'pkgconf'.

> Or is it that it uses gcc instead of full x86_64-pc-linux-gnu-gcc that
> you're meaning with unqualified compiler?

No. Practically gcc and x86_64-pc-linux-gnu-gcc are the same thing on your system.

[Comment 21 Sergei Trofimovich (RETIRED) 2019-03-17 21:08:04 UTC]

> Attachment #569166 [details, diff] - Attachment is obsolete: true
I think that was mostly correct fix.

[Comment 22 tt_1 2019-03-20 18:17:45 UTC]

possibly, it is just that I lack of a deeper understanding for this problem, and so I'm not really able to upstream this. I might be able to technically send the patch, but not much more than that. Neither asking somebody else to do it for me :)

[Comment 23 Sergei Trofimovich (RETIRED) 2019-03-20 23:17:25 UTC]

This bug contains quite a bit of details. I can try to explain things that are not yet clear for you. You cal name a few facts discovered in this bug that don't match your assumptions and we can sort it out.

[Comment 24 Matt Turner 2019-05-03 06:57:11 UTC]

Does this patch help? https://gitlab.freedesktop.org/xorg/lib/libxt/merge_requests/23

[Comment 25 Sergei Trofimovich (RETIRED) 2019-05-03 10:07:48 UTC]

Looks correct. Reassigning to x11@.

[Comment 26 Matt Turner 2019-05-07 01:18:31 UTC]

Patch is now upstream. I'm expecting a release soon, so I'm not going to apply the patch immediately.

[Comment 27 tt_1 2019-05-24 13:15:41 UTC]

It seems that upstream rejected the patch?

[Comment 28 Sergei Trofimovich (RETIRED) 2019-05-24 17:10:09 UTC]

No. It was merged as https://gitlab.freedesktop.org/xorg/lib/libxt/commit/0b80bc9904c8d553c760651daca0c964df052c8b

[Comment 29 Matt Turner 2019-06-17 14:41:53 UTC]

v1.2.0 will be released shortly, and then we'll mark this closed.

[Comment 30 Larry the Git Cow 2019-06-22 00:28:41 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cf7d005d74e118d4beddd5202f337b0be7fe8ca0

commit cf7d005d74e118d4beddd5202f337b0be7fe8ca0
Author:     Matt Turner <[e-mail]>
AuthorDate: 2019-06-22 00:14:12 +0000
Commit:     Matt Turner <[e-mail]>
CommitDate: 2019-06-22 00:27:53 +0000

    x11-libs/libXt: Version bump to 1.2.0
    
    Closes: https://bugs.gentoo.org/679938
    Signed-off-by: Matt Turner <[e-mail]>

 x11-libs/libXt/Manifest           |  1 +
 x11-libs/libXt/libXt-1.2.0.ebuild | 30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

[Comment 31 tt_1 2019-06-22 04:53:26 UTC]

yeah, thank you! :)

[Comment 32 Matt Turner 2019-06-22 22:44:55 UTC]

Excellent, thanks for confirming!