Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
On Tuesday 15 October 2013 16:37:32 Peter Korsgaard wrote: Mike your e-mail client still sucks btw Sorry, in what way? the quoting style unreasonably mangles things -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On Monday 14 October 2013 12:43:34 Steve Ellcey wrote: I am new to building uclibc, but have experience building glibc and newlib, and I have a question about the best way to build multiple versions of uclibc from a script without any user interaction. you have experience building the kernel though right ? uClibc largely behaves the same as that. Currently, I run 'make defconfig' to create a default .config file and then use grep to modify the .config file before each build (strip out some lines and then append my versions back in). I.e. I remove the ARCH_BIG_ENDIAN=y line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from big-endian to little-endian or I may pick a different MIPS ABI. But what I noticed is that when I run the normal 'make' command after modifying .config is that my .config changes are getting wiped out and .config is getting restored to a default state. try `make oldconfig` first (assuming you pass ARCH=/etc... on the command line) Can someone explain why this is happening and if there is a way to prevent it? Is there a better way to do multiple uclibc builds with different defaults and without requiring any user interaction? usually the simplest thing is to create the .config files by hand as you care about them, and then use those when building alternatively, we could update our kconfig snapshot to the latest kernel which would get use miniconfig support -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Building uclibc for big-endian and little-endian target.
On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Building uclibc for big-endian and little-endian target.
On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. - Sedat - [1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.33.2/100-fritzbox_specific_arch_flags.freetz.patch ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Building uclibc for big-endian and little-endian target.
On Wed, Oct 16, 2013 at 10:23 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger vap...@gentoo.org wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. - Sedat - [1] http://freetz.org/browser/trunk/toolchain/make/target/uclibc/0.9.33.2/100-fritzbox_specific_arch_flags.freetz.patch Just two details... Freetz supports mostly MIPS based router boxes. 2nd, check which minimum gcc-version supports certain CPU/arch flags (some projects still uses ancient gcc in their toolchains) :-)! - Sedat - ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64
Mike == Mike Frysinger vap...@gentoo.org writes: Hi, On Tuesday 15 October 2013 16:37:32 Peter Korsgaard wrote: Mike your e-mail client still sucks btw Sorry, in what way? the quoting style unreasonably mangles things The supercite 'name' thing? I kind of like it, but I've turned it off for @uclibc.org. -- Bye, Peter Korsgaard ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Building uclibc for big-endian and little-endian target.
On Wednesday 16 October 2013 04:23:17 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. that patch is exactly the sort of thing we are not adding more support for -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: non-interactive build question
This seems to work but I would still like to try and find a way to generate the .config file I want without having to run menuconfig at all. I think what I would really like is something like: You'll only have to run menuconfig manually once. Once you have a good set of config files it should be easy to manipulate them to produce other variants you like. I can't see how you can avoid the first manual menuconfig step personally. Qais ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: non-interactive build question
On 2013-10-16, Qais Yousef qais.you...@imgtec.com wrote:
This seems to work but I would still like to try and find a way to
generate the .config file I want without having to run menuconfig at
all. I think what I would really like is something like:
You'll only have to run menuconfig manually once.
Once you have a good set of config files it should be easy to
manipulate them to produce other variants you like. I can't see how
you can avoid the first manual menuconfig step personally.
Manipulating .config files programmatically is pretty easy.
The shell script I use to build a buildroot-based system doesn't
require any use of menuconfig.
The one thing you have to remember when manipulating a .config file is
that changing a config value often has side effects. For example: when
you want to enable and configure a previously disabled subsystem, you
have to do it in stages:
1) Enable the subsystem
2) Run make oldconfig to make the subsystem's configuration items
appear in the .config file with default values.
3) Enable/Disable/Set the subsystem's configuration items.
Depending on how the configuration items are defined, you can end up
with this process nesting several levels deep.
To that end, here are 3 bash functions I use:
set -o nounset
set -o errexit
# low level functions used to manipulate linux kernel-style .config
# files.
function SyncConfig()
{
yes '' | $Make oldconfig /dev/null
}
# By default, UnsetValue and SetValue will, after modifying the
# .config file, do a make oldconfig to re-normalize the .config
# file. Use the -n option to prevent that.
function UnsetValue()
{
dosync=y
test $1 = '-n' { dosync=n; shift; }
Variable=$1
echo UnsetValue $Variable
sed -i s/^${Variable}=.*/# ${Variable} is not set/g .config
test $dosync = y SyncConfig
return 0
}
function SetValue()
{
dosync=y
test $1 = '-n' { dosync=n; shift; }
Variable=$1
# default value is 'y'
Value=${2-y}
echo SetValue $Variable $Value
# if value isn't 'y', then put it in double quotes
test $Value != y Value=\$Value\
# escape any slashes
Value=${Value//\//\\\/}
sed -i s/^${Variable}=.*/${Variable}=${Value}/g .config
sed -i s/^# ${Variable} is not set.*/${Variable}=${Value}/g .config
test $dosync = y SyncConfig
return 0
}
Then you can make function calls like this in a build script:
TPath=/path/to/my/toolchain
SetValue BR2_TOOLCHAIN_EXTERNAL_PATH $TPath
--
Grant Edwards grant.b.edwardsYow! Now that I have my
at APPLE, I comprehend COST
gmail.comACCOUNTING!!
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: Building uclibc for big-endian and little-endian target.
On Wed, Oct 16, 2013 at 5:23 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 16 October 2013 04:23:17 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. that patch is exactly the sort of thing we are not adding more support for Hi Mike, what had you in mind, how would you realize it? Regards, - Sedat - ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: Building uclibc for big-endian and little-endian target.
On Wednesday 16 October 2013 12:13:12 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 5:23 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 16 October 2013 04:23:17 Sedat Dilek wrote: On Wed, Oct 16, 2013 at 9:04 AM, Mike Frysinger wrote: On Tuesday 15 October 2013 15:00:40 Khem Raj wrote: On Oct 15, 2013, at 10:30 AM, Steve Ellcey wrote: I have a question about endiness and uclibc. I am trying to build multiple versions of uclibc for MIPS, including big and little endian versions. What I notice is that in Rules.mak there are lines: CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB to add -EL or -EB to linker commands (this seems to be generic for all architectures). What I do not see is any generic (or MIPS specific) code to add -EL or -EB to CPU_CFLAGS (or CPU_FLAGS-y to be exact). I am wondering if there is a specific reason for this? Right now the uclibc build seems to assume that the compiler I am using to build uclibc will always generate the correct endiness without any flags. That was consensus we had some time ago. Otherwise these flags were getting too many and difficult to deal with. well, i think that was more focused on cpu/arch/tune flags. we still have endian flags in there for various targets. adding the right logic for mips would be OK imo. As the Freetz router project had to deal with BE/LE issues, we (yes, I was more active these days) decided to define the Kconfig logic in: extra/Configs/Config.mips ...and added the the CPU_FLAGS-* (CPU optimization etc.) stuff to... Rules.mak Please see the patch in [1] for more details. that patch is exactly the sort of thing we are not adding more support for what had you in mind, how would you realize it? as Khem said, if you want to target a specific cpu (-march/-mtune/etc...), then update UCLIBC_EXTRA_CFLAGS accordingly. there's really no difference between a Kconfig option with hardcoded cpu name and the user adding the same name to the cflags. except the kconfig list is a constantly losing route. -mike signature.asc Description: This is a digitally signed message part. ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
