sdkdir in xorg-server.pc
Hi all,
xorg-server.pc has the variables sdkdir=${prefix}/include/xorg and
moduledir=${exec_prefix}/lib/xorg/modules. These are used by some Xorg packages to add to the include and library search path.
We patch pkgconf to add the sysroot to the variables includedir, mapdir
and libdir. Should we do something similar for sdkdir and moduledir? But of course, there's no end to that...
By the way, Peter, Thomas, do the autobuilders ever compile the full
Xorg server? I don't see how xdriver_xf86-input-synaptics can ever build with this issue...
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Arnout" == Arnout Vandecappelle <[email protected]> writes:
Arnout> Hi all,
Arnout> xorg-server.pc has the variables sdkdir=${prefix}/include/xorg and Arnout> moduledir=${exec_prefix}/lib/xorg/modules. These are used by some Xorg Arnout> packages to add to the include and library search path.
Arnout> We patch pkgconf to add the sysroot to the variables includedir, Arnout> mapdir and libdir. Should we do something similar for sdkdir and Arnout> moduledir? But of course, there's no end to that...
Indeed :/ I guess we have to..
Arnout> By the way, Peter, Thomas, do the autobuilders ever compile Arnout> the full Xorg server? I don't see how
Arnout> xdriver_xf86-input-synaptics can ever build with this issue...
They should as long as the needed toolchain dependencies are available (wchar/largefile/c++).
gcc10.fsffrance.org uses:
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
So that should be sufficient. Gcc14/114 don't have C++. Thomas' glibc toolchains should also catch it.
Signature · 1 line
Bye, Peter Korsgaard
Dear Peter Korsgaard,
Quoted 9 lines · Peter Korsgaard
Arnout> By the way, Peter, Thomas, do the autobuilders ever compile Arnout> the full Xorg server? I don't see how
Arnout> xdriver_xf86-input-synaptics can ever build with this issue...They should as long as the needed toolchain dependencies are available (wchar/largefile/c++).
gcc10.fsffrance.org uses:
Quoted 8 lines
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=ySo that should be sufficient. Gcc14/114 don't have C++. Thomas' glibc toolchains should also catch it.
And in practice full X.org never gets selected, see the mail I just sent on the same thread, which explains what's happening.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Dear Arnout Vandecappelle,
Quoted 3 lines · Arnout Vandecappelle
By the way, Peter, Thomas, do the autobuilders ever compile the full
Xorg server? I don't see how xdriver_xf86-input-synaptics can ever build with this issue...
No, they don't. I did some experiments, and there is a bug in kconfig that prevents the modular X.org build from ever being chosen.
After conducting a few experiments, it turns out that randpackageconfig does not make a random selection for choice...enchoice constructs: it always uses the default choice.
Rather than the slightly more complicated X.org server example, let's take the libjpeg/jpeg-turbo example (see package/jpeg/Config.in).
If we use "make randconfig" itself, then we properly have both choices:
$ while true ; do echo "==" ; make randconfig > /dev/null 2>&1 ; grep -E "BR2_PACKAGE_(LIBJPEG|JPEG_TURBO)(=y| is not set)" .config ; done == # BR2_PACKAGE_LIBJPEG is not set BR2_PACKAGE_JPEG_TURBO=y == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == # BR2_PACKAGE_LIBJPEG is not set BR2_PACKAGE_JPEG_TURBO=y == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == ^CBR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == # BR2_PACKAGE_LIBJPEG is not set BR2_PACKAGE_JPEG_TURBO=y ==
However, if you use "make randpackageconfig", libjpeg will always be selected (unless of course your CPU has NEON or MMX, in which case it will always select jpeg-turbo):
$ while true ; do echo "==" ; make randpackageconfig > /dev/null 2>&1 ; grep -E "BR2_PACKAGE_(LIBJPEG|JPEG_TURBO)(=y| is not set)" .config ; done == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set == BR2_PACKAGE_LIBJPEG=y # BR2_PACKAGE_JPEG_TURBO is not set ==
Looking deeper into the kconfig code, it appears that in the following code in confdata.c:
for_all_symbols(i, csym) {
if (sym_has_value(csym) || !sym_is_choice(csym))
continue;
sym_calc_value(csym);
if (mode == def_random)
randomize_choice_values(csym);
else
set_all_choice_values(csym);
}which handles the randomization of choices, all choices have "sym_has_value(csym)" true, even the ones that had no value defined in .config.nopkg. If we remove this test, then the choices are properly randomized, but then of course even the choices that had a value set in .config.nopkg (such as target architecture variant, strip tool, etc.) are randomized, which is not what we want.
So, the problem is that when a partial configuration file (.config.nopkg) is loaded using KCONFIG_ALLCONFIG, all the choices are marked as having a value even if it's not the case.
In order to track down the issue, I've produced a minimal test case, which allows to reproduce the problem even on the kernel's latest kconfig code (as of 3.8-rc7).
Take the following Config.test.in:
-----8<----------8<------------8<----------
config OPTIONA
bool "Option A"
choice
prompt "This is a choice"
config CHOICE_OPTIONA
bool "Choice Option A"
config CHOICE_OPTIONB
bool "Choice Option B"
endchoice
config OPTIONB
bool "Option B"
-----8<----------8<------------8<----------
If you do (using the kernel's kconfig):
./scripts/kconfig/conf --randconfig Config.test.in
you will see that the generated .config file properly randomizes all options, including CHOICE_OPTIONA and CHOICE_OPTIONB.
Now, if we create a partial .config (named orig.config) file to set the value of some options:
-----8<----------8<------------8<----------CONFIG_OPTIONA=y
-----8<----------8<------------8<----------
If you do:
KCONFIG_ALLCONFIG=orig.config ./scripts/kconfig/conf --randconfig Config.test.in
and look@the resulting .config, you will see that:
* CONFIG_OPTIONA is always set to y, which is OK.
* CONFIG_OPTIONB is properly randomized
* But in the choice, it's always CONFIG_CHOICE_OPTIONA that will be selected, and never CONFIG_CHOICE_OPTIONB. The randomization for choices doesn't work as soon as a file is passed as KCONFIG_ALLCONFIG.
I've tried to dive again into kconfig code, but sigh, it is quite hard to understand. I will report this bug together with its minimal test case to the linux-kbuild@ mailing list.
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com