[Buildroot] sdkdir in xorg-server.pc

[Buildroot] sdkdir in xorg-server.pc

[Arnout Vandecappelle]

  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
-- 
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

[Buildroot] sdkdir in xorg-server.pc

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> 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.

-- 
Bye, Peter Korsgaard

[Buildroot] sdkdir in xorg-server.pc

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Fri, 15 Feb 2013 00:59:30 +0100, Arnout Vandecappelle wrote:

>   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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] sdkdir in xorg-server.pc

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Sun, 17 Feb 2013 23:08:54 +0100, Peter Korsgaard wrote:

>  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.

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com