Re: [ptxdist] Ptxdist for mpc8313 rdb
On 09/23/2010 12:42 PM, Flavio de Castro Alves Filho wrote: Hello, I am currently trying to build a ptxdist application for the Freescale PowerPC MPC8313 RDB board. I configured the linux kernel 2.6.34 using the 83xx/mpc8313_rdb_defconfig configuration file and compiled with the gcc 4.3.2 from the OSELAS toolchain project for the powerpc-603e. All the compilation works fine, from both kernel and root filesystem. When I load the kernel to the board, the kernel is correctly load and uncompressed but the boot does not occur. After the uncompression, it hangs. The kernel is loaded in the memory position 0x100 and the bootargs is rw console=ttys0,115200 root=/dev/nfs. Does anybody have any idea about what is causing this problem? The console device should be ttyS0 (upper case matters) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Problems compiling the system in redhat 4
On 02/19/2010 02:27 PM, Jose M. Gomez Cama wrote: I am trying to compile the toolchain in scientific linux 4, equivalent to redhat 4. I am using the ptxdist version 2010.01.0 and the OSELAS.Toolchain version 1.99.3.6. There is a problem with ptxdist when it finds the make version 3.80. The solution is to substitute: if test $MAJOR_MAKE_VERSION -eq 3 -a $MINOR_MAKE_VERSION -lt 81 -o $MAJOR_MAKE_VERSION -lt 3 ; then by if test $MAJOR_MAKE_VERSION -eq 2 -a $MINOR_MAKE_VERSION -lt 81 -o $MAJOR_MAKE_VERSION -lt 3 ; then Then I have found a problem with readlink ptxdist select ptxconfigs/arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig readlink: invalid option -- e Try `readlink --help' for more information. info: selected ptxconfig: 'ptxconfigs/arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig' Is there any solution. Move forward to the 21st century (Red Hat 4 is so old!) Honestly, a lot of the tools you'll need may not be compatible with such an old system. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Perl?
On 12/01/2009 11:13 AM, Carsten Schlote wrote: Am Montag, den 30.11.2009, 10:50 -0700 schrieb Gary Thomas: Has anyone any experience with adding perl to ptxdist? Yes. I ported perl to ptxdist (we need it for webmin). Works fine, but it is a huge blob of bits and bytes :-( Maybe you could share? I too am trying to get webmin running :-) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Perl?
On 11/30/2009 11:31 AM, Robert Schwebel wrote: On Mon, Nov 30, 2009 at 10:50:31AM -0700, Gary Thomas wrote: Has anyone any experience with adding perl to ptxdist? Yes, but no good ones :-) Seriously - we should have a look at what OE is doing there. I've seen that they actually have something. I've looked at the OE setup and it's not pretty :-) I guess I'll slog on with this since I'm in need of Perl... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Can't build X server
On 10/22/2009 07:00 AM, Michael Olbrich wrote: Hi, On Wed, Oct 21, 2009 at 12:59:38PM -0600, Gary Thomas wrote: checking for X11... configure: error: Package requirements (xextproto xtrans xcb= 1.1.92) were not met: No package 'xtrans' found I can reproduce this. We're working on the correct solution. Until it's done you can you can work around this by copying platform-test_arm/sysroot-target/usr/share/pkgconfig/xtrans.pc to platform-test_arm/sysroot-target/usr/lib/pkgconfig/xtrans.pc and then run 'ptxdist go' again. Thanks, I'll see how much farther along I can get. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Can't build X server
Trying to build xorg+xfbdev server from latest git tree, I get: build-target/xorg-server-1.6.3/dix/dixfonts.c:1912: undefined reference to `fs_register_fpe_functions' What am I missing? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Can't build X server
On 10/21/2009 10:54 AM, Robert Schwebel wrote:
Hi Garry,
On Wed, Oct 21, 2009 at 10:27:01AM -0600, Gary Thomas wrote:
Trying to build xorg+xfbdev server from latest git tree, I get:
build-target/xorg-server-1.6.3/dix/dixfonts.c:1912: undefined reference to
`fs_register_fpe_functions'
What am I missing?
The bad news is: the support for x.org in the ptxdist mainline is a
little bit outdated.
The good news: Here [1] is a super duper new branch which contains the
latest and greatest x.org stuff, currently in something like the state
of upstream from last friday.
Michael has tested this on x86 a little bit and it seems to work. I plan
to merge this branch shortly into the mainline, so it would be very
helpful if you test against it and report back about the results.
Note that the branch is rebased from time to time.
rsc
[1] http://git.pengutronix.de/?p=rsc/ptxdist;a=shortlog;h=refs/heads/rsc-xorg
Not much better, I'm afraid. I now get this error:
checking for X11... configure: error: Package requirements (xextproto xtrans xcb
= 1.1.92) were not met:
No package 'xtrans' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables X11_CFLAGS
and X11_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** [/local/arm_test/platform-test_arm/state/xorg-lib-x11.prepare] Error 1
My config files are attached, in case you care to try and duplicate this.
Thanks for any ideas
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
#
# Automatically generated make config: don't edit
# PTXdist version: 1.99.svn
#
PTXCONF_PLATFORMCONFIG_VERSION=1.99.svn
PTXCONF__platformconfig_MAGIC__=y
#
#
#
#
# Target Platform Configuration
#
#
#
#
PTXCONF_PLATFORM=test_arm
PTXCONF_PLATFORM_VERSION=
#
# architecture
#
# PTXCONF_ARCH_ALPHA is not set
# PTXCONF_ARCH_AVR is not set
PTXCONF_ARCH_ARM=y
# PTXCONF_ARCH_BLACKFIN is not set
# PTXCONF_ARCH_X86 is not set
# PTXCONF_ARCH_MINGW is not set
# PTXCONF_ARCH_PPC is not set
# PTXCONF_ARCH_M68K is not set
# PTXCONF_ARCH_SPARC is not set
# PTXCONF_ARCH_MIPS is not set
# PTXCONF_ARCH_CRIS is not set
# PTXCONF_ARCH_PARISC is not set
# PTXCONF_ARCH_SH is not set
# PTXCONF_ARCH_ARM_ATMEL is not set
# PTXCONF_ARCH_ARM_AT91RM9200 is not set
# PTXCONF_ARCH_ARM_AT91SAM926X is not set
# PTXCONF_ARCH_ARM_EPXA is not set
# PTXCONF_ARCH_ARM_IMX is not set
# PTXCONF_ARCH_ARM_IXP is not set
# PTXCONF_ARCH_ARM_LPC32XX is not set
# PTXCONF_ARCH_ARM_NETX is not set
PTXCONF_ARCH_ARM_OMAP=y
# PTXCONF_ARCH_ARM_PXA is not set
PTXCONF_ARCH_SUPPORTS_ENDIAN_LITTLE=y
# PTXCONF_ENDIAN_BIG is not set
PTXCONF_ENDIAN_LITTLE=y
# PTXCONF_HAS_HARDFLOAT is not set
PTXCONF_HAS_MMU=y
PTXCONF_SIZEOF_LONG_DOUBLE=8
PTXCONF_ARCH_STRING=arm
#
# toolchain
#
PTXCONF_CROSSCHAIN_VENDOR=
PTXCONF_CROSSCHAIN_CHECK=
PTXCONF_GLIBC_VERSION=2.8
PTXCONF_GNU_TARGET=arm-linux
PTXCONF_COMPILER_PREFIX=${PTXCONF_GNU_TARGET}-
PTXCONF_COMPILER_PREFIX_KERNEL=${PTXCONF_COMPILER_PREFIX}
PTXCONF_COMPILER_PREFIX_UBOOT=${PTXCONF_COMPILER_PREFIX}
#
# extra toolchain options
#
PTXCONF_TARGET_EXTRA_CPPFLAGS=
PTXCONF_TARGET_EXTRA_CFLAGS=
PTXCONF_TARGET_EXTRA_CXXFLAGS=
PTXCONF_TARGET_EXTRA_LDFLAGS=
#
# paths directories
#
PTXCONF_SYSROOT_TARGET=${PTXDIST_PLATFORMDIR}/sysroot-target
PTXCONF_SYSROOT_HOST=${PTXDIST_PLATFORMDIR}/sysroot-host
PTXCONF_SYSROOT_CROSS=${PTXDIST_PLATFORMDIR}/sysroot-cross
# PTXCONF_KERNEL is not set
# PTXCONF_HOST_DTC is not set
# PTXCONF_DTC is not set
#
# console options
#
PTXCONF_CONSOLE_NAME=ttyS0
PTXCONF_CONSOLE_SPEED=115200
#
# bootloaders
#
# PTXCONF_GRUB is not set
# PTXCONF_U_BOOT is not set
# PTXCONF_U_BOOT_V2 is not set
#
# flash
#
#
#
#
#
# Partition sizes can be in decimal or in hex (0x) with
#
#
# an optional k|M for kilobytes or megabytes
#
#
# A partition size of 0 means that the remaining space
#
#
# is used for a partition
#
#
#
#
PTXCONF_FLASH_START=0xff00
PTXCONF_FLASH_SIZE=16M
PTXCONF_FLASH_BLOCKSIZE=128k
#
# --
#
#
# partitions
#
#
# --
#
PTXCONF_FLASH_PART1_SIZE=256k
PTXCONF_FLASH_PART1_NAME=ubootl
PTXCONF_FLASH_PART2_SIZE=1792k
PTXCONF_FLASH_PART2_NAME=kernel
PTXCONF_FLASH_PART3_SIZE=13312k
PTXCONF_FLASH_PART3_NAME=jffs2
PTXCONF_FLASH_PART4_SIZE=256k
PTXCONF_FLASH_PART4_NAME=uboot
PTXCONF_FLASH_PART5_SIZE=128k
PTXCONF_FLASH_PART5_NAME=oftree
PTXCONF_FLASH_PART6_SIZE=
PTXCONF_FLASH_PART6_NAME=space
#
# image creation options
#
#
# ipkg options
#
# PTXCONF_IMAGE_IPKG_IMAGE_FROM_REPOSITORY is not set
[ptxdist] Install macro
Has anyone come up with a macro or recipe to install a whole [sub]directory into a target package? Currently, I'm doing something like this (but it's not really pretty): files=$$(cd $(PKG_DIR)/extra_dir find . -type f | sed s/^\.//); \ for i in $$files; do \ access=$$(stat -c %a $(PKG_DIR)/extra_dir/$$i); \ $(call install_copy, xxx, 0, 0, $$access, $(PKG_DIR)/extra_dir/$$i, /usr/$$i, n); \ done files=$$(cd $(PKG_DIR)/extra_dir find . -type l | sed s/^\.//); \ for i in $$files; do \ link=$$(readlink $(PKG_DIR)/extra_dir/$$i); \ $(call install_link, xxx, $$link, /usr/$$i); \ done Any ideas? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Makefile confusions
I'm working with PTXdist [close to] the trunk/mainline. Occasionally, I get warnings like these: /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:34: warning: overriding commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.get' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:34: warning: ignoring old commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.get' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:38: warning: overriding commands for target `/opt/ptx.text/lib/ptxdist-1.99.svn/src/libpthread-stubs-0.1.tar.bz2' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:38: warning: ignoring old commands for target `/opt/ptx.text/lib/ptxdist-1.99.svn/src/libpthread-stubs-0.1.tar.bz2' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:48: warning: overriding commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.extract' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:48: warning: ignoring old commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.extract' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:71: warning: overriding commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.prepare' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:71: warning: ignoring old commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.prepare' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:85: warning: overriding commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.compile' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:85: warning: ignoring old commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.compile' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:96: warning: overriding commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.install' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:96: warning: ignoring old commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.install' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:107: warning: overriding commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.targetinstall' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:107: warning: ignoring old commands for target `/local/cobra_X/platform-amltd_arm/state/libpthread-stubs.targetinstall' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:115: warning: overriding commands for target `libpthread-stubs_clean' /opt/ptx.text/lib/ptxdist-1.99.svn/rules/libpthread-stubs.make:115: warning: ignoring old commands for target `libpthread-stubs_clean' Any hints what causes this? how to remove them? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] QT?
Robert Schwebel wrote: On Mon, Jan 26, 2009 at 03:26:18AM -0700, Gary Thomas wrote: Robert Schwebel wrote: On Mon, Jan 26, 2009 at 03:05:47AM -0700, Gary Thomas wrote: Has anyone built QT lately? I'm trying, using the latest trunk, to build for ARM (GCC 4.3.2) and it fails :-( We are working on 4.5. It is much faster than anything before that version, because it does native fixedpoint arithmetics. Any schedule? Depends on customer interest and spare time... Fair enough. I'm mostly looking for something non-X to run on my shiny new graphic hardware :-) What kind of hardware is it? And *how* shiny? :-) TI OMAP3 (Zoom1) I got it to test Android, but now I want to see what else I can do with it... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Install problem
Using the latest trunk, I can no longer make install as non-root :-( cp: cannot create regular file `/etc/bash_completion.d/ptxdist': Permission denied -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] QT?
Has anyone built QT lately? I'm trying, using the latest trunk, to build for ARM (GCC 4.3.2) and it fails :-( arm-linux-g++ -c -pipe -I/tmp/arm_test/platform-amltd_arm/sysroot-target/usr/include/freetype2 -O2 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_RASTER_IMAGEENGINE -DQT_RASTER_PAINTENGINE -DQT_NO_FONTCONFIG -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_NETWORK_LIB -DQT_CORE_LIB -I../../mkspecs/qws/linux-ptx-g++ -I. -I../../include/QtCore -I../../include/QtCore -I../../include/QtNetwork -I../../include/QtNetwork -I../../include -I../../include/QtGui -I.rcc/release-static-emb-arm -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-static-emb-arm -I.uic/release-static-emb-arm -I/tmp/arm_test/platform-amltd_arm/sysroot-target/include -I/tmp/arm_test/platform-amltd_arm/sysroot-target/usr/include -o .obj/release-static-emb-arm/qwscursor_qws.o embedded/qwscursor_qws.cpp In file included from ../../include/QtGui/private/qapplication_p.h:1, from embedded/qdirectpainter_qws.cpp:43: ../../include/QtGui/private/../../../src/gui/kernel/qapplication_p.h:347: error: multiple parameters named 'screen' -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Local sources
I've seen that I can put almost anything in my project tree that mirrors the basic tree (e.g. rules/*.in show up in the menu). How can I specify a directory for my sources that's also local to my project (I always keep the staged sources around, so I'd like to just populate the project with them + these source tarballs will not be public in any way) Is there a macro (like PTXDIST_TOPDIR) that I can use to mean the current [staged/cloned] project path? Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Python
Robert Schwebel wrote: On Tue, Nov 25, 2008 at 08:50:46AM -0700, Gary Thomas wrote: What's the reason for having the version of Python tied to the configuration symbol, e.g. PYTHON24 vs PYTHON30? I'm not ready to use Python 3.0, but I would like to move forward to Python 2.5.1. Having this configuration coupling as is, it makes it tough to move to a different version. n.b. I don't see any similar coupling for other packages... The problem is that, for a certain time, we need to go with more than one version in parallel. - we cannot cross compile python 2.4 from x86_64 to ARM at the moment - python 3.0 is highly experimental and I suspect that not all packages out there are already usable with it - we have production code out there that uses 2.4, so I cannot drop it right now. So for the moment, please see PYTHON24 as just a name for a packet. Do you see a problem with that approach? Understood. I need something newer than 2.4.2 and not 3.0, so I'll just make additional PYTHON25 packet. I will think about this and see if I can come up with a more elegant solution. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] [PATCH] Simplify make
Marc Kleine-Budde wrote:
Robert Schwebel wrote:
On Fri, Nov 21, 2008 at 03:42:15PM -0700, Gary Thomas wrote:
From: Gary Thomas [EMAIL PROTECTED]
By only including those [sub] makefiles which are actually used in the
build, the process runs faster and also avoids the dreaded error
'bash: line too long'
Are you actually affected by this problem? Where do you think will it
hit us first?
I have suffered from this for a long time. While not fatal, it makes
reading any output from make nearly impossible. It also slows the
whole process down.
Signed-off-by: Gary Thomas [EMAIL PROTECTED]
---
--- /work/ptxdist-trunk/rules/other/Toplevel.make 2008-11-19
07:55:29.0 -0700
+++ /tmp/ptx-2008_11_21/ptx/rules/other/Toplevel.make 2008-11-19
08:07:42.0 -0700
@@ -37,7 +37,7 @@ include $(wildcard $(PROJECTPRERULESDIR)
endif
#include $(PTX_DGEN_DEPS_PRE)
-include $(PTX_DGEN_RULESFILES_MAKE)
+include $(PTX_DGEN_RULESFILES_MAKE_MIN)
include $(PTX_DGEN_DEPS_POST)
include $(PTX_MAP_ALL_MAKE)
--- /work/ptxdist-trunk/scripts/lib/ptxd_lib_dgen.sh2008-11-14
06:38:57.0 -0700
+++ /tmp/ptx-2008_11_21/ptx/scripts/lib/ptxd_lib_dgen.sh2008-11-19
07:45:17.0 -0700
@@ -41,6 +41,30 @@ ptxd_dgen_rulesfiles() {
) ${PTX_DGEN_RULESFILES}
sed -e s/\(.*\)/include \1/ ${PTX_DGEN_RULESFILES}
${PTX_DGEN_RULESFILES_MAKE}
+
+# Compute minimal set of makefiles
+
+# Compute the package strings
+xargs ${PTX_DGEN_RULESFILES} fgrep -h 'PACKAGES-$'
${PTXDIST_TEMPDIR}/pkg_names
Nice trick to get rid of the cmdline length limitation.
please use double quotes () around the variables to protect against
spaces in files names. Ladis is working to get ptxdist running on windows.
+
+cat ${PTXDIST_TEMPDIR}/show_pkgs EOF
+# Read in configuration
+include ${PTXDIST_PTXCONFIG}
+include ${PTXDIST_PLATFORMCONFIG}
+
+# Figure out packages
+include ${PTXDIST_TEMPDIR}/pkg_names
+
+all:
+ @echo \${PACKAGES-y} \${PACKAGES-m} \${HOST_PACKAGES-y}
\${HOST_PACKAGES-m} \${CROSS_PACKAGES-y} \${CROSS_PACKAGES-m}
you'll miss the PACKAGES -y-y and -y-m. See Toplevel.make
Simple enough to add :-)
+EOF
+
+PKGS=`make -f ${PTXDIST_TEMPDIR}/show_pkgs`
+( for i in ${PKGS}; do
+ grep /${i} ${PTX_DGEN_RULESFILES_MAKE}
+done ) ${PTX_DGEN_RULESFILES_MAKE_MIN}
Here you assume, that the PKG correspond directly to the file name,
there might be subtle differences in case and/or usage of hyphen vs.
underscore.
We have a file state/ptx_map_all.sh which contains a database to map
from PACKAGE name to file name. This file can be extended to map from
package name to file name.
However the grep over the makefile names probably handles the case
when building a host packet while not enabling the target packet.
The beauty of the whole process is that it uses the extant makefiles
to do all the substitutions - no assumptions on spelling, etc, necessary.
+
+
}
--- /work/ptxdist-trunk/scripts/ptxdist_vars.sh 2008-11-14
06:38:57.0 -0700
+++ /tmp/ptx-2008_11_21/ptx/scripts/ptxdist_vars.sh 2008-11-19
07:45:18.0 -0700
@@ -27,6 +27,7 @@ PTX_DGEN_DEPS_PRE=${STATEDIR}/ptx_dgen_d
PTX_DGEN_DEPS_POST=${STATEDIR}/ptx_dgen_deps.post
PTX_DGEN_RULESFILES=${STATEDIR}/ptx_dgen_rulesfiles
PTX_DGEN_RULESFILES_MAKE=${PTX_DGEN_RULESFILES}.make
+PTX_DGEN_RULESFILES_MAKE_MIN=${PTX_DGEN_RULESFILES}_min.make
PTX_MAP_ALL=${STATEDIR}/ptx_map_all.sh
PTX_MAP_ALL_MAKE=${PTX_MAP_ALL}.make
cheers, Marc
Thanks. I'll post an updated patch soon.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
ptxdist mailing list
ptxdist@pengutronix.de
[ptxdist] [PATCH] minor spelling error
From: Gary Thomas [EMAIL PROTECTED] Fix minor spelling error (in comment only): Signed-off-by: Gary Thomas [EMAIL PROTECTED] --- --- /work/ptxdist-trunk/bin/ptxdist 2008-11-19 07:55:32.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/bin/ptxdist 2008-11-19 08:07:44.0 -0700 @@ -1882,7 +1882,7 @@ setup_path setup_logfile # -- logfile is ready setup_export -# -- all improtant vars are exported +# -- all important vars are exported check_uid check_path -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] [PATCH] only build testing tools if necessary
From: Gary Thomas [EMAIL PROTECTED] Many times, the testing tools/infrastructure may not be wanted/needed. These changes allow those tools to not be built if not wanted. Signed-off-by: Gary Thomas [EMAIL PROTECTED] --- --- /work/ptxdist-trunk/rules/host-ckermit.in 2008-10-29 07:41:07.0 -0600 +++ /tmp/ptx-2008_11_21/ptx/rules/host-ckermit.in 2008-11-19 07:44:29.0 -0700 @@ -1,5 +1,5 @@ ## SECTION=hosttools_noprompt config HOST_CKERMIT bool - default y + default n --- /work/ptxdist-trunk/rules/host-lrzsz.in 2008-11-03 06:37:51.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/rules/host-lrzsz.in 2008-11-19 07:44:28.0 -0700 @@ -1,4 +1,5 @@ ## SECTION=hosttools_noprompt config HOST_LRZSZ bool + default n --- /work/ptxdist-trunk/rules/host-testframe.in 1969-12-31 17:00:00.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/rules/host-testframe.in 2008-08-28 08:42:09.0 -0600 @@ -0,0 +1,5 @@ +menuconfig HOST_TESTFRAME + bool + prompt Host-side testing framework + select HOST_LRZSZ + select HOST_CKERMIT --- /work/ptxdist-trunk/rules/hosttools.in 2008-10-29 07:41:46.0 -0600 +++ /tmp/ptx-2008_11_21/ptx/rules/hosttools.in 2008-11-19 07:44:53.0 -0700 @@ -10,6 +10,7 @@ comment -- source rules/host-gettext.in source rules/host-intltool.in +source rules/host-testframe.in # automatically selected host tools source generated/hosttools_noprompt.in -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] [PATCH] Relaxed DHCP timing
From: Gary Thomas [EMAIL PROTECTED] BusyBox DHCP timeout is a bit aggressive on slow embedded targets. Note: perhaps in future this might be configurable. Signed-off-by: Gary Thomas [EMAIL PROTECTED] --- --- /work/ptxdist-trunk/patches/busybox-1.10.4/generic/discover_timeout.patch 1969-12-31 17:00:00.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/patches/busybox-1.10.4/generic/discover_timeout.patch 2008-09-12 15:41:45.0 -0600 @@ -0,0 +1,11 @@ +--- busybox-1.10.4.OLD/networking/udhcp/dhcpc.c2008-06-25 04:55:22.0 -0600 busybox-1.10.4/networking/udhcp/dhcpc.c2008-09-12 15:40:07.0 -0600 +@@ -139,7 +139,7 @@ + char *str_W; + #endif + int tryagain_timeout = 20; +- int discover_timeout = 3; ++ int discover_timeout = 15; + int discover_retries = 3; + uint32_t xid = 0; + uint32_t lease_seconds = 0; /* can be given as 32-bit quantity */ -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] [PATCH] Simplify make
From: Gary Thomas [EMAIL PROTECTED]
By only including those [sub] makefiles which are actually used in the
build, the process runs faster and also avoids the dreaded error
'bash: line too long'
Signed-off-by: Gary Thomas [EMAIL PROTECTED]
---
--- /work/ptxdist-trunk/rules/other/Toplevel.make 2008-11-19
07:55:29.0 -0700
+++ /tmp/ptx-2008_11_21/ptx/rules/other/Toplevel.make 2008-11-19
08:07:42.0 -0700
@@ -37,7 +37,7 @@ include $(wildcard $(PROJECTPRERULESDIR)
endif
#include $(PTX_DGEN_DEPS_PRE)
-include $(PTX_DGEN_RULESFILES_MAKE)
+include $(PTX_DGEN_RULESFILES_MAKE_MIN)
include $(PTX_DGEN_DEPS_POST)
include $(PTX_MAP_ALL_MAKE)
--- /work/ptxdist-trunk/scripts/lib/ptxd_lib_dgen.sh2008-11-14
06:38:57.0 -0700
+++ /tmp/ptx-2008_11_21/ptx/scripts/lib/ptxd_lib_dgen.sh2008-11-19
07:45:17.0 -0700
@@ -41,6 +41,30 @@ ptxd_dgen_rulesfiles() {
) ${PTX_DGEN_RULESFILES}
sed -e s/\(.*\)/include \1/ ${PTX_DGEN_RULESFILES}
${PTX_DGEN_RULESFILES_MAKE}
+
+# Compute minimal set of makefiles
+
+# Compute the package strings
+xargs ${PTX_DGEN_RULESFILES} fgrep -h 'PACKAGES-$'
${PTXDIST_TEMPDIR}/pkg_names
+
+cat ${PTXDIST_TEMPDIR}/show_pkgs EOF
+# Read in configuration
+include ${PTXDIST_PTXCONFIG}
+include ${PTXDIST_PLATFORMCONFIG}
+
+# Figure out packages
+include ${PTXDIST_TEMPDIR}/pkg_names
+
+all:
+ @echo \${PACKAGES-y} \${PACKAGES-m} \${HOST_PACKAGES-y}
\${HOST_PACKAGES-m} \${CROSS_PACKAGES-y} \${CROSS_PACKAGES-m}
+EOF
+
+PKGS=`make -f ${PTXDIST_TEMPDIR}/show_pkgs`
+( for i in ${PKGS}; do
+ grep /${i} ${PTX_DGEN_RULESFILES_MAKE}
+done ) ${PTX_DGEN_RULESFILES_MAKE_MIN}
+
+
}
--- /work/ptxdist-trunk/scripts/ptxdist_vars.sh 2008-11-14 06:38:57.0
-0700
+++ /tmp/ptx-2008_11_21/ptx/scripts/ptxdist_vars.sh 2008-11-19
07:45:18.0 -0700
@@ -27,6 +27,7 @@ PTX_DGEN_DEPS_PRE=${STATEDIR}/ptx_dgen_d
PTX_DGEN_DEPS_POST=${STATEDIR}/ptx_dgen_deps.post
PTX_DGEN_RULESFILES=${STATEDIR}/ptx_dgen_rulesfiles
PTX_DGEN_RULESFILES_MAKE=${PTX_DGEN_RULESFILES}.make
+PTX_DGEN_RULESFILES_MAKE_MIN=${PTX_DGEN_RULESFILES}_min.make
PTX_MAP_ALL=${STATEDIR}/ptx_map_all.sh
PTX_MAP_ALL_MAKE=${PTX_MAP_ALL}.make
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
ptxdist mailing list
ptxdist@pengutronix.de
[ptxdist] [PATCH] JFFS2 blocksize in hex
From: Gary Thomas [EMAIL PROTECTED] Hex makes much more sense when specifying the [erase] block size of a FLASH device. Signed-off-by: Gary Thomas [EMAIL PROTECTED] --- --- /work/ptxdist-trunk/platforms/image_jffs2.in2008-11-14 06:39:13.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/platforms/image_jffs2.in2008-11-21 15:33:28.0 -0700 @@ -12,8 +12,8 @@ menuconfig IMAGE_JFFS2 if IMAGE_JFFS2 config IMAGE_JFFS2_BLOCKSIZE - int - default -1 + hex + default 0x1 prompt Erase Block Size help Enter here the size of each (sector) block in target's flash device. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] [PATCH] Build C-kermit on target
From: Gary Thomas [EMAIL PROTECTED] This patch allows the C-Kermit tool to be built for the target. Current support is only host-side. Note: attribution remains with Oscar Peredo, as the makefile is virtually the same as the host-side version. Signed-off-by: Gary Thomas [EMAIL PROTECTED] --- --- /work/ptxdist-trunk/patches/cku211/generic/cross-build.patch 1969-12-31 17:00:00.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/patches/cku211/generic/cross-build.patch 2008-08-28 08:37:32.0 -0600 @@ -0,0 +1,19 @@ +--- cku211/makefile2004-04-17 12:52:00.0 -0600 cku211.NEW/makefile2007-09-26 08:42:39.0 -0600 +@@ -1406,13 +1406,12 @@ + + ckctel.$(EXT): ckcsym.h ckcdeb.h ckcker.h ckcnet.h ckctel.h ckclib.h + +-wart: ckwart.$(EXT) +- $(CC) $(LNKFLAGS) -o wart ckwart.$(EXT) $(LIBS) ++HOST_CC := $(CC) ++wart: ckwart.c ++ $(HOST_CC) -o wart ckwart.c + + ckcmdb.$(EXT): ckcmdb.c ckcdeb.h ckcsym.h ckclib.h + +-ckwart.$(EXT): ckwart.c +- + ckudia.$(EXT): ckudia.c ckcker.h ckcdeb.h ckucmd.h ckcasc.h ckcsym.h ckcsig.h \ + ckcnet.h ckctel.h ckclib.h + --- /work/ptxdist-trunk/rules/ckermit.in1969-12-31 17:00:00.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/rules/ckermit.in2008-11-21 15:14:07.0 -0700 @@ -0,0 +1,9 @@ +## SECTION=communication +menuconfig CKERMIT + tristate + prompt Columbia Univ 'kermit' terminal program + select NCURSES + help + Basic file transfer terminal control + + --- /work/ptxdist-trunk/rules/ckermit.make 1969-12-31 17:00:00.0 -0700 +++ /tmp/ptx-2008_11_21/ptx/rules/ckermit.make 2008-08-28 08:41:46.0 -0600 @@ -0,0 +1,137 @@ +# $Id: template 2516 2005-04-25 10:29:55Z rsc $ +# +# Copyright (C) 2005 by Oscar Peredo +# +# See CREDITS for details about who has contributed to this project. +# +# For further information about the PTXdist project and license conditions +# see the README file. +# + +# +# We provide this package +# +PACKAGES-$(PTXCONF_CKERMIT) += ckermit + +# +# Paths and names +# +CKERMIT_VERSION= 211 +CKERMIT= cku$(CKERMIT_VERSION) +CKERMIT_SUFFIX = tar.gz +CKERMIT_URL= http://www.columbia.edu/kermit/ftp/archives/$(CKERMIT).$(CKERMIT_SUFFIX) +CKERMIT_SOURCE = $(SRCDIR)/$(CKERMIT).$(CKERMIT_SUFFIX) +CKERMIT_DIR= $(BUILDDIR)/$(CKERMIT) + + +# +# Get +# + +ckermit_get: $(STATEDIR)/ckermit.get + +$(STATEDIR)/ckermit.get: $(ckermit_get_deps_default) + @$(call targetinfo, $@) + @$(call touch, $@) + +$(CKERMIT_SOURCE): + @$(call targetinfo, $@) + @$(call get, CKERMIT) + +# +# Extract +# + +ckermit_extract: $(STATEDIR)/ckermit.extract + +$(STATEDIR)/ckermit.extract: $(ckermit_extract_deps_default) + @$(call targetinfo, $@) + @$(call clean, $(CKERMIT_DIR)) + mkdir -p $(CKERMIT_DIR) + @$(call extract, CKERMIT, $(CKERMIT_DIR)) + @$(call patchin, CKERMIT, $(CKERMIT_DIR)) + @$(call touch, $@) + +# +# Prepare +# + +ckermit_prepare: $(STATEDIR)/ckermit.prepare + +CKERMIT_PATH = PATH=$(CROSS_PATH) +CKERMIT_ENV= $(CROSS_ENV) + +# +# autoconf +# +CKERMIT_AUTOCONF = $(CROSS_AUTOCONF_USR) +CKERMIT_DEPS = $(ckermit_prepare_deps_default) + +$(STATEDIR)/ckermit.prepare: $(CKERMIT_DEPS) + @$(call targetinfo, $@) + @$(call clean, $(CKERMIT_DIR)/config.cache) + @$(call touch, $@) + +# +# Compile +# + +ckermit_compile: $(STATEDIR)/ckermit.compile + +#CKERMIT_BUILD_OPTS= make xermit KTARGET=linuxa CC=powerpc-linux-gcc CC2=gcc CFLAGS=-O -DLINUX -pipe -funsigned-char -DFNFLOAT -DCK_POSIX_SIG -DCK_NEWTERM -DTCPSOCKET -DLINUXFSSTND -DNOCOTFMC -DPOSIX -DUSE_STRERROR -DCK_NCURSES -I/usr/include/ncurses -DHAVE_PTMX -DHAVE_BAUDBOY -DHAVE_CRYPT_H -k HOST_CC=gcc +CKERMIT_BUILD_OPTS = xermit KTARGET=linuxa +CKERMIT_BUILD_OPTS += CC=$(CROSS_CC) CC2=$(CROSS_CC) +CKERMIT_BUILD_OPTS += CFLAGS=$(CROSS_CPPFLAGS) -DLINUX -DFNFLOAT -DCK_POSIX_SIG -DCK_NEWTERM -DTCPSOCKET -DLINUXFSSTND -DNOCOTFMC -DPOSIX -DUSE_STRERROR -DCK_NCURSES -DHAVE_PTMX +CKERMIT_BUILD_OPTS += LNKFLAGS=$(CROSS_LDFLAGS) +CKERMIT_BUILD_OPTS += LIBS=-lncurses -lm -lcrypt -lresolv +CKERMIT_BUILD_OPTS += HOST_CC=gcc + +$(STATEDIR)/ckermit.compile: $(ckermit_compile_deps_default) + @$(call targetinfo, $@) + cd $(CKERMIT_DIR
Re: [ptxdist] CAN utils
Juergen Beisert wrote: Gary, On Dienstag, 11. November 2008, Gary Thomas wrote: Index: rules/canutils.in === --- rules/canutils.in (revision 9080) +++ rules/canutils.in (working copy) @@ -2,7 +2,6 @@ menuconfig CANUTILS tristate prompt canutils - select KERNEL help The canutils package contains tools to configure and test the Socket CAN framework. Does it also work for you, if you do a ptxdist clean kernel ptxdist targetinstall canutils? KERNEL should be kept active, because its header files are needed. Builds fine for me without KERNEL (which gets in my way because I use a totally separate kernel source tree) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Local kernel trees (was Re: CAN utils)
Gary Thomas wrote: Wolfram Sang wrote: Hello Gary, Assume that I have a totally local kernel tree - how can I use this? Also assume that I don't [necessarily] need/want ptxdist to bother building my kernel. How can I configure things to work in this way? The current state of local kernel trees looks like this: Assuming we want to use a tree in /home/wsa/kernel/worktrees/fancyboard First call: ptxdist setup - Source directories - Prefix for kernel trees (/home/wsa/kernel/worktrees/) then: ptxdist platformconfig - Linux kernel - Kernel version (enter here the dirname of the tree you want to use, here 'fancyboard') - Local kernel tree (activate it) Your build-target-directory will then contain a symlink named linux-fancyboard pointing to the local tree. Is this what you had in mind? Close, but I'm still fuzzy on a couple of details. * Why not just specify the whole kernel source path, rather than the [obscure in my mind] prefix + version. I have kernel source trees all over the place and having to rerun 'setup' to build seems problematic. * How do I specify a particular kernel configuration? Currently, I will build my kernel like this: % mkdir /work/new_kernel % make -C /work/kernel_source O=/work/new_kernel platform_defconfig % make O=/work/new_kernel oldconfig % make O=/work/new_kernel zImage Thanks for helping with this. BTW, I'd also be very happy to just provide the path to an already built configured kernel, instead of expecting ptxdist to manage this for me. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] CAN utils
Juergen Beisert wrote:
Gary,
On Dienstag, 11. November 2008, Gary Thomas wrote:
Juergen Beisert wrote:
On Dienstag, 11. November 2008, Gary Thomas wrote:
Index: rules/canutils.in
===
--- rules/canutils.in (revision 9080)
+++ rules/canutils.in (working copy)
@@ -2,7 +2,6 @@
menuconfig CANUTILS
tristate
prompt canutils
- select KERNEL
help
The canutils package contains tools to configure
and test the Socket CAN framework.
Does it also work for you, if you do a ptxdist clean kernel ptxdist
targetinstall canutils?
KERNEL should be kept active, because its header files are needed.
Builds fine for me without KERNEL (which gets in my way because
I use a totally separate kernel source tree)
So it seems your are having an already built kernel around in your BSP?
Because the canutils.make contains these lines:
#
# Prepare
#
[...]
$(STATEDIR)/canutils.prepare:
@$(call targetinfo)
@$(call clean, $(CANUTILS_DIR)/config.cache)
cd $(CANUTILS_DIR) \
$(CANUTILS_PATH) $(CANUTILS_ENV) \
CPPFLAGS=-I${KERNEL_DIR}/include $${CPPFLAGS} \
./configure $(CANUTILS_AUTOCONF)
@$(call touch)
Here the ${KERNEL_DIR} is used.
${KERNEL_DIR} is not set in my configuration, so this ends up
just as ... -I/include ... It doesn't seem to hurt.
That said, I'd like to understand how I can play by the rules.
Assume that I have a totally local kernel tree - how can I use
this? Also assume that I don't [necessarily] need/want ptxdist
to bother building my kernel.
How can I configure things to work in this way?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
ptxdist mailing list
ptxdist@pengutronix.de
[ptxdist] CAN utils
I'm trying to build the CAN utilities package and having trouble. Firstly, it seems to expect the [berlios.de] SocketCAN include tree, but nothing in the configuration points at that. Also, programs which are not selected by the configuration are still built, just not installed. Most particularly, I'm having trouble with 'canconfig': canconfig.c: In function 'do_show_baudrate': canconfig.c:66: error: 'SIOCGCANBAUDRATE' undeclared (first use in this function) canconfig.c:66: error: (Each undeclared identifier is reported only once canconfig.c:66: error: for each function it appears in.) canconfig.c: In function 'do_set_baudrate': canconfig.c:94: error: 'SIOCSCANBAUDRATE' undeclared (first use in this function) canconfig.c: In function 'cmd_mode': canconfig.c:114: error: 'can_mode_t' undeclared (first use in this function) canconfig.c:114: error: 'mode' undeclared (first use in this function) canconfig.c:114: error: expected expression before ')' token canconfig.c:126: error: 'SIOCSCANMODE' undeclared (first use in this function) Any pointers on how to get this built? n.b. I'm running 1.99.svn (r8991) Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Local kernel trees (was Re: CAN utils)
Wolfram Sang wrote: On Tue, Nov 11, 2008 at 07:40:58AM -0700, Gary Thomas wrote: Close, but I'm still fuzzy on a couple of details. * Why not just specify the whole kernel source path, rather than the [obscure in my mind] prefix + version. I have kernel source trees all over the place and having to rerun 'setup' to build seems problematic. It is problematic and it is not finished yet. What I would like to have is to have access to my own git-repository with lots of branches (like one for every ptxdist-project). The time I added this feature, I thought it might be a good way to have all of my branches checked out as seperate trees. This is why there is a prefix and the version (=branch). But I am not quite sure about this approach, as I'm also still not quite sure of my git-workflow managing BSPs and upstream at the same time. It might be an idea to be able to specify a path as a version. Hmmm * How do I specify a particular kernel configuration? Currently, In the above approach you can use 'ptxdist kernelconfig'. That means it will work with $PLATFORM_CONFIGDIR/kernelconfig-version and put it into the kernel-dir as .config. I will build my kernel like this: % mkdir /work/new_kernel % make -C /work/kernel_source O=/work/new_kernel platform_defconfig % make O=/work/new_kernel oldconfig % make O=/work/new_kernel zImage Looks like you want to build a number of kernels from one tree? Yes. Is there any way to just use a pre-built tree? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Local kernel trees (was Re: CAN utils)
Wolfram Sang wrote: Hello Gary, Assume that I have a totally local kernel tree - how can I use this? Also assume that I don't [necessarily] need/want ptxdist to bother building my kernel. How can I configure things to work in this way? The current state of local kernel trees looks like this: Assuming we want to use a tree in /home/wsa/kernel/worktrees/fancyboard First call: ptxdist setup - Source directories - Prefix for kernel trees (/home/wsa/kernel/worktrees/) then: ptxdist platformconfig - Linux kernel - Kernel version (enter here the dirname of the tree you want to use, here 'fancyboard') - Local kernel tree (activate it) Your build-target-directory will then contain a symlink named linux-fancyboard pointing to the local tree. Is this what you had in mind? Close, but I'm still fuzzy on a couple of details. * Why not just specify the whole kernel source path, rather than the [obscure in my mind] prefix + version. I have kernel source trees all over the place and having to rerun 'setup' to build seems problematic. * How do I specify a particular kernel configuration? Currently, I will build my kernel like this: % mkdir /work/new_kernel % make -C /work/kernel_source O=/work/new_kernel platform_defconfig % make O=/work/new_kernel oldconfig % make O=/work/new_kernel zImage Thanks for helping with this. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Autogenerated .in files
Robert Schwebel wrote: Hi, just a short note on another milestone on our way to ptxdist-2.0: Marc has recently implemented autogeneration of menues. That means that you can now throw a .in file into your projcect's rules/ directory (just like you could with a .make file) and have it *automaticall* integrated into the menu. Without any twiddeling with Kconfig. In order to test it, you need: - ptxdist-trunk - run autogen.sh there - ./configure - make Packages are now put into sections. Kconfig files include these autogenerated section files with sniplets like this one: menu System Libraries source generated/system_libraries.in endmenu Now all you have to do is to specify which section a .in file belongs into: ## SECTION=system_libraries rest of the .in file Trunk seems to work, there may be minor issues, so please test and report your experiences back to us! I just tried merging this with my local tree (my only changes are additions, config files, etc). Using a working config, I get a bunch of warnings (ptx.errs - attached). It also dies trying to build udev (ptx.errs2) Any pointers? -- Gary Thomas | Consulting for the MLB Associates |Embedded world [EMAIL PROTECTED] test_ppc]$ ptxdist go .config:939:warning: trying to assign nonexistent symbol UDEV_OPT_DEBUG .config:940:warning: trying to assign nonexistent symbol UDEV_OPT_SYSLOG .config:945:warning: trying to assign nonexistent symbol UDEV_EXTRA_ATA_ID .config:946:warning: trying to assign nonexistent symbol UDEV_EXTRA_CDROM_ID .config:947:warning: trying to assign nonexistent symbol UDEV_EXTRA_COLLECT .config:948:warning: trying to assign nonexistent symbol UDEV_EXTRA_EDD_ID .config:949:warning: trying to assign nonexistent symbol UDEV_EXTRA_FIRMWARE .config:950:warning: trying to assign nonexistent symbol UDEV_EXTRA_FLOPPY .config:951:warning: trying to assign nonexistent symbol UDEV_EXTRA_FSTAB_IMPORT .config:952:warning: trying to assign nonexistent symbol UDEV_EXTRA_PATH_ID .config:953:warning: trying to assign nonexistent symbol UDEV_EXTRA_RULE_GENERATOR .config:954:warning: trying to assign nonexistent symbol UDEV_EXTRA_SCSI_ID .config:955:warning: trying to assign nonexistent symbol UDEV_EXTRA_USB_ID .config:956:warning: trying to assign nonexistent symbol UDEV_EXTRA_VOLUME_ID .config:961:warning: trying to assign nonexistent symbol UDEV_INSTALL_TEST_UDEV .config:962:warning: trying to assign nonexistent symbol UDEV_INSTALL_ETC_INITD_UDEV .config:963:warning: trying to assign nonexistent symbol UDEV_INSTALL_ETC_INITD_UDEV_DEFAULT .config:964:warning: trying to assign nonexistent symbol UDEV_INSTALL_ETC_INITD_UDEV_USER .config:965:warning: trying to assign nonexistent symbol UDEV_RC_D_LINK .config:966:warning: trying to assign nonexistent symbol ROOTFS_ETC_UDEV_CONF .config:967:warning: trying to assign nonexistent symbol ROOTFS_ETC_UDEV_CONF_DEFAULT .config:968:warning: trying to assign nonexistent symbol ROOTFS_ETC_UDEV_CONF_USER .config:969:warning: trying to assign nonexistent symbol ROOTFS_UDEV_DEFAULT_RULES .config:1333:warning: trying to assign nonexistent symbol CYCLICTEST rules/host-mtd-utils.in:4:warning: 'select' used by config symbol 'HOST_MTD_UTILS' refers to undefined symbol 'HOST_LIBLZO' .config:120:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_START .config:121:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_SIZE .config:122:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_BLOCKSIZE .config:135:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART1_SIZE .config:136:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART1_NAME .config:137:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART2_SIZE .config:138:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART2_NAME .config:139:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART3_SIZE .config:140:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART3_NAME .config:141:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART4_SIZE .config:142:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART4_NAME .config:143:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART5_SIZE .config:144:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART5_NAME .config:145:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART6_SIZE .config:146:warning: trying to assign nonexistent symbol BOARDSETUP_FLASH_PART6_NAME udevd.c: In function 'init_uevent_netlink_sock': udevd.c:739: error: 'SO_RCVBUFFORCE' undeclared (first use in this function) udevd.c:739: error: (Each undeclared identifier is reported only once udevd.c:739: error: for each function it appears in.) make[4]: *** [udevd.o
[ptxdist] Install directory hierarchy?
Is there any [simple] way to install a complete tree into the target? I'd like to be able to write a single macro to copy an entire tree, e.g. from sysroot-target into my target root. I've seen lots of cases of installing a file or two, or in the case of Python, even a whole sub-tree, but this all seems quite complex. Any ideas/pointers? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Hardwired packages
Robert Schwebel wrote: On Wed, Aug 27, 2008 at 03:39:13PM -0600, Gary Thomas wrote: I've noticed that in the latest PTXdist (I'm running r8788), there are a couple of host packages that always get built, but don't seem to be used - certainly not by me. selected_ptxconfig:PTXCONF_HOST_LRZSZ=y selected_ptxconfig:PTXCONF_HOST_CKERMIT=y These are always enabled in the *.in files. Is there a good reason for this? Can they be made optional? The idea behind kermit is that we use it for the integrated test suite, dito with lrzsz. However, we can make it optional when the concept for the test suite is finished (which is one of the remaining release blockers). I figured as much. I'm not keen on building things I don't use, so I've built up this patch. -- Gary Thomas | Consulting for the MLB Associates |Embedded world Index: rules/host-lrzsz.in === --- rules/host-lrzsz.in (revision 4468) +++ rules/host-lrzsz.in (working copy) @@ -1,4 +1,4 @@ config HOST_LRZSZ bool - default y + default n Index: rules/host-ckermit.in === --- rules/host-ckermit.in (revision 4468) +++ rules/host-ckermit.in (working copy) @@ -1,4 +1,4 @@ config HOST_CKERMIT bool - default y + default n Index: rules/host-testframe.in === --- rules/host-testframe.in (revision 0) +++ rules/host-testframe.in (revision 0) @@ -0,0 +1,5 @@ +menuconfig HOST_TESTFRAME + bool + prompt Host-side testing framework + select HOST_LRZSZ + select HOST_CKERMIT Index: rules/hosttools.in === --- rules/hosttools.in (revision 4468) +++ rules/hosttools.in (working copy) @@ -10,6 +10,7 @@ source rules/host-gettext.in source rules/host-intltool.in +source rules/host-testframe.in # automatically selected host tools -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Hardwired packages
I've noticed that in the latest PTXdist (I'm running r8788), there are a couple of host packages that always get built, but don't seem to be used - certainly not by me. selected_ptxconfig:PTXCONF_HOST_LRZSZ=y selected_ptxconfig:PTXCONF_HOST_CKERMIT=y These are always enabled in the *.in files. Is there a good reason for this? Can they be made optional? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Python packages
Michael Olbrich wrote: Hi, On Thu, Aug 21, 2008 at 03:03:04PM -0600, Gary Thomas wrote: I'd like to add a python package to my PTXdist tree. The key thing will be to run python setup.py install in the target-install step in such a way that any non-python pieces get built correctly. For example, trying to install Cheetah requires the use of the target GCC in order to build a [binary] wrapper. Ideas/help? in the compile stage: $(CROSS_ENV) PATH=$(CROSS_PATH) LDSHARED=$(CROSS_CC) -shared \ python setup.py build The LDSHARED stuff is a hack. Without it setup.py picks the correct compiler from $(CROSS_ENV) but uses gcc -shared to link. The quotes will get lost at some point so -shared become a parameter for CROSS_CC. in the install stage: python setup.py install --prefix=$(SYSROOT)/usr in the targetinstall stage: @$(call install_copy, libpv, 0, 0, 0644, \ $(SYSROOT)/usr/lib/python2.4/site-packages/libfoo.so, \ /usr/lib/python2.4/site-packages/libfoo.so) for all libs. It's not perfect but it should work. This is a great start, thanks. Perhaps you have a package that you could share the actual files for? One that's not in the SVN tree... I'll see what I can do with these ideas. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Python packages
Robert Schwebel wrote: On Fri, Aug 22, 2008 at 05:16:57AM -0600, Gary Thomas wrote: This is a great start, thanks. Note, nevertheless, that my comments stay true even with the above. It somehow works, but is not reliable. Fair enough. I'm only interested in x86 - PPC, so I should be OK. Perhaps you have a package that you could share the actual files for? One that's not in the SVN tree... I'll see what I can do with these ideas. We could add the latest libpv version to the tree. Michael, we must do that for an upcoming project anyway, so please go ahead. I'd appreciate this a lot, thanks. Once I get the Cheetah (and possibly others) package working, I can contribute them back to the project. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Python packages
I'd like to add a python package to my PTXdist tree. The key thing will be to run python setup.py install in the target-install step in such a way that any non-python pieces get built correctly. For example, trying to install Cheetah requires the use of the target GCC in order to build a [binary] wrapper. I don't see any examples of how to do this. The closest thing is myghty (sorely out of date BTW), but it merrily glosses over the target install. Ideas/help? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Project files
I'm trying to run the latest SVN (r8744). Where do I get [sample/starting] project files? I tried to just use some old ones, but no-go. These were ptxconfig files I used roughly 6 months ago with the SVN version of that time. Any pointers/help to get me off the dime would be appreciated. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Project files
Juergen Beisert wrote:
Hi Gary
On Freitag, 15. August 2008, Gary Thomas wrote:
I'm trying to run the latest SVN (r8744).
Where do I get [sample/starting] project files? I tried to
just use some old ones, but no-go. These were ptxconfig files
I used roughly 6 months ago with the SVN version of that time.
Any pointers/help to get me off the dime would be appreciated.
Currently I'm going to test new generic projects. But its not finished yet.
Perhaps the first pieces of the new FAQ will help you.
New FAQ? I didn't see a pointer to that on the web page.
I followed the process [below] and got something to build. It would be
nice to see an example setup/prject, even if incomplete.
How do I save my setup(s) so the next time around I can just clone?
--
Migrating a ptxdist-1 project into a ptxdist-2 project.
To convert a ptxdist-1 project into a ptxdist-2 project simply copy your
old ptxconfig file into the files selected_ptxconfig
_and_ selected_platform.
After that, run a ptxdist platformconfig, check if everything is set up
correctly*) and save these settings. All in the platform unused symbols will
now be discarded and the remaining required symbols and their values are
saved to the selected_platform file.
I had to edit the version strings to get this to work.
Repeat the same with ptxdist menuconfig. In this case all for userland
configuration unused symbols are discarded from the original ptxconfig file
settings and the remaining are saved to the selected_ptxconfig file.
Now you have successfully separated platform and userland configuration. This
is the main configuration ptxdist-2 uses.
*) At least if you are using Busybox as your shell environment you must check
carefully if all settings in the previous Busybox version are still present.
Each version of Busybox changes various used symbolnames, so it could happen
that some settings are lost during the transition.
--
How to set up a ptxdist-2 project and still have the feeling it's a ptxdist-1
project:
- Omit the platform name (e.g. keep this menu entry empty)
- Open the selected_platformconfig file with an editor and search for
SYSROOT_TARGET, SYSROOT_HOST and SYSROOT_CROSS. Replace their default
settings with:
For SYSROOT_TARGET: ${PTXDIST_WORKSPACE}/local/${GNU_TARGET}
For SYSROOT_HOST: ${PTXDIST_WORKSPACE}/local-host
For SYSROOT_CROSS: ${PTXDIST_WORKSPACE}/local-cross
With these settings you get the same directory structure in a ptxdist-2
project than with ptxdist-1.
--
How to retain the old behaviour of ptxdist-1 in my ptxdist-2 project while
handling local sources instead of source archieves?
Keep the packetname_SOURCE variable empty in your local source rule file.
--
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
ptxdist mailing list
ptxdist@pengutronix.de
Re: [ptxdist] inetutils update
Marc Kleine-Budde wrote: Hi, Gary Thomas wrote: Small patch to update inetutils package to [latest] 1.5 please update to latest -trunk before generating the patch. Please add Subject, From and Signed-off-by according to the cannolocial patch format. Will do (next time). Note: my change also obviates the patches for the previous version, so you can delete that directory as well. Thanks for being so responsive -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Can't install from trunk
I just updated to the latest trunk (r7721). I'm running an up-to-date Fedora 8 system. When I try to install I get this: [EMAIL PROTECTED] ptxdist-0.10-trunk]$ ./configure --prefix=/opt/ptx.test checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for gawk... gawk checking for egrep... (cached) grep -E checking for a BSD-compatible install... /usr/bin/install -c checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for bison... bison -y checking whether #! works in shell scripts... yes checking for bash... /bin/bash checking for sed... /bin/sed checking sed version... 4.1.5 checking for bunzip2... /usr/bin/bunzip2 checking for gunzip... /bin/gunzip checking for readlink... /usr/bin/readlink checking for awk... /bin/awk checking for mktemp... /bin/mktemp checking for pkg-config... /usr/bin/pkg-config checking whether python finds distutils... yes checking for patch... /usr/bin/patch checking whether /usr/bin/patch will work... yes checking for dirname... yes checking for cat... yes checking for find... yes checking for sort... yes configure: creating ./config.status config.status: creating Makefile config.status: creating scripts/ptxdist_version.sh config.status: creating rules/ptxdist-version.in ptxdist version 0.10.svn configured. Using '/opt/ptx.test' for installation prefix. Report bugs to ptxdist@pengutronix.de [EMAIL PROTECTED] ptxdist-0.10-trunk]$ make building conf... cd /home/gthomas/ptxdist-0.10-trunk/scripts/kconfig \ make conf [EMAIL PROTECTED]@ make[1]: Entering directory `/home/gthomas/ptxdist-0.10-trunk/scripts/kconfig' cc -DCURSES_LOC=ncurses.h -DKBUILD_NO_NLS -c conf.c -o conf.o cp zconf.tab.c_shipped zconf.tab.c cp lex.zconf.c_shipped lex.zconf.c cp zconf.hash.c_shipped zconf.hash.c sed lkc_proto.h lkc_defs.h 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' cc -DCURSES_LOC=ncurses.h -DKBUILD_NO_NLS -c zconf.tab.c -o zconf.tab.o cc conf.o zconf.tab.o -o conf @CONF_LIBS@ cc: @CONF_LIBS@: No such file or directory make[1]: *** [conf] Error 1 make[1]: Leaving directory `/home/gthomas/ptxdist-0.10-trunk/scripts/kconfig' make: *** [all] Error 2 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Can't install from trunk
Marc Kleine-Budde wrote: Gary Thomas wrote: I just updated to the latest trunk (r7721). I'm running an up-to-date Fedora 8 system. When I try to install I get this: [EMAIL PROTECTED] ptxdist-0.10-trunk]$ ./configure --prefix=/opt/ptx.test checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for gawk... gawk checking for egrep... (cached) grep -E checking for a BSD-compatible install... /usr/bin/install -c checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for bison... bison -y checking whether #! works in shell scripts... yes checking for bash... /bin/bash checking for sed... /bin/sed checking sed version... 4.1.5 checking for bunzip2... /usr/bin/bunzip2 checking for gunzip... /bin/gunzip checking for readlink... /usr/bin/readlink checking for awk... /bin/awk checking for mktemp... /bin/mktemp checking for pkg-config... /usr/bin/pkg-config checking whether python finds distutils... yes checking for patch... /usr/bin/patch checking whether /usr/bin/patch will work... yes checking for dirname... yes checking for cat... yes checking for find... yes checking for sort... yes configure: creating ./config.status config.status: creating Makefile config.status: creating scripts/ptxdist_version.sh config.status: creating rules/ptxdist-version.in ptxdist version 0.10.svn configured. Using '/opt/ptx.test' for installation prefix. Report bugs to ptxdist@pengutronix.de [EMAIL PROTECTED] ptxdist-0.10-trunk]$ make building conf... cd /home/gthomas/ptxdist-0.10-trunk/scripts/kconfig \ make conf [EMAIL PROTECTED]@ make[1]: Entering directory `/home/gthomas/ptxdist-0.10-trunk/scripts/kconfig' cc -DCURSES_LOC=ncurses.h -DKBUILD_NO_NLS -c conf.c -o conf.o cp zconf.tab.c_shipped zconf.tab.c cp lex.zconf.c_shipped lex.zconf.c cp zconf.hash.c_shipped zconf.hash.c sed lkc_proto.h lkc_defs.h 's/P(\([^,]*\),.*/#define \1 (\*\1_p)/' cc -DCURSES_LOC=ncurses.h -DKBUILD_NO_NLS -c zconf.tab.c -o zconf.tab.o cc conf.o zconf.tab.o -o conf @CONF_LIBS@ cc: @CONF_LIBS@: No such file or directory make[1]: *** [conf] Error 1 make[1]: Leaving directory `/home/gthomas/ptxdist-0.10-trunk/scripts/kconfig' make: *** [all] Error 2 try ./autogen.sh first Thanks, that helped. Perhaps there should be a note in 'README'? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Build error with ptx-1.99.svn and GTK
Robert Schwebel wrote: On Fri, Dec 07, 2007 at 11:49:00PM +0100, Marco Cavallini wrote: Hello I get the following error building xorg+GTK stuff with the latest ptx. Does anybody already tried doing that? Are the following ICONV settings enough? Any hint will be appreciated. Please send me your ptxconfig off-list. I've struggled with this as well. Once you have it worked out, can you publish the results as an example? Thanks -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Testing 1.0.1
Juergen Beisert wrote: Gary, On Friday 02 November 2007 17:53, Gary Thomas wrote: Gary Thomas wrote: Juergen Beisert wrote: Gary, On Friday 02 November 2007 14:27, Gary Thomas wrote: Better use the OSELAS.Toolchain-Project. It supports more recent toolchains, the crosstool part is outdated. I got started on this, but ran into some troubles. The GCC snapshot gcc-4.2-20070207 is no longer available, so I tried to build the tools using the released version of gcc-4.2.2. This went pretty well, until I tried to build busybox: /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.2.2-glibc-2.5- kern el-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32:2 7: error: bits/syscall.h: No such file or directory Hmm, GCC 4.2.2 in OSELAS.Toolchain-1.1.0? Did you select this version of gcc by your own? Perhaps you should start with GCC 4.1.2 from the OSELAS.Toolchain-1.1.0 project. Or wait for our next OSELAS.Toolchain release. This also should support GCC 4.2. As mentioned, I tried to select the configuration which uses gcc-4.2-20070207, but that is no longer available, so I tried to use the released version gcc-4.2.2 I'm trying 4.1.2 now. Sadly, I get the same error. /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.1.2-glibc-2.5-kern el-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32:27: error: bits/syscall.h: No such file or directory Has anyone successfully built an i586 toolchain and then used it to build ptxdist-1.0.1 (OSELAS.BSP-Pengutronix-GenericI586Glibc-3)? Attached my toolchain I'm using for my x86 terminal projects. But it has to be built with ptxdist-0.10.6! And note: All OSELAS.Toolchains in 1.1.0 are tested with ptxdist-0.10.6 only. I took your toolchain setup and rebuilt using 0.10.6, then I tried my [default] configuration on 1.0.1 and got the same result :-( /opt/OSELAS.Toolchain-1.1.0/i586-pmmx-linux-gnu/gcc-4.1.2-glibc-2.5-kernel-2.6.18/sysroot-i586-pmmx-linux-gnu/usr/include/sys/syscall.h:32:27: error: bits/syscall.h: No such file or directory Juergen - perhaps you could put your actual toolchain on my FTP site? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Testing 1.0.1
Juergen Beisert wrote: Hi Gary, On Sunday 04 November 2007 18:41, Gary Thomas wrote: Juergen Beisert wrote: On Friday 02 November 2007 17:53, Gary Thomas wrote: Gary Thomas wrote: Juergen Beisert wrote: Gary, On Friday 02 November 2007 14:27, Gary Thomas wrote: Better use the OSELAS.Toolchain-Project. It supports more recent toolchains, the crosstool part is outdated. I got started on this, but ran into some troubles. The GCC snapshot gcc-4.2-20070207 is no longer available, so I tried to build the tools using the released version of gcc-4.2.2. This went pretty well, until I tried to build busybox: /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.2.2-glibc-2. 5- kern el-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32 :2 7: error: bits/syscall.h: No such file or directory Hmm, GCC 4.2.2 in OSELAS.Toolchain-1.1.0? Did you select this version of gcc by your own? Perhaps you should start with GCC 4.1.2 from the OSELAS.Toolchain-1.1.0 project. Or wait for our next OSELAS.Toolchain release. This also should support GCC 4.2. As mentioned, I tried to select the configuration which uses gcc-4.2-20070207, but that is no longer available, so I tried to use the released version gcc-4.2.2 I'm trying 4.1.2 now. Sadly, I get the same error. /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.1.2-glibc-2.5-k ern el-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32:27 : error: bits/syscall.h: No such file or directory Has anyone successfully built an i586 toolchain and then used it to build ptxdist-1.0.1 (OSELAS.BSP-Pengutronix-GenericI586Glibc-3)? Attached my toolchain I'm using for my x86 terminal projects. But it has to be built with ptxdist-0.10.6! And note: All OSELAS.Toolchains in 1.1.0 are tested with ptxdist-0.10.6 only. I took your toolchain setup and rebuilt using 0.10.6, then I tried my [default] configuration on 1.0.1 and got the same result :-( /opt/OSELAS.Toolchain-1.1.0/i586-pmmx-linux-gnu/gcc-4.1.2-glibc-2.5-kernel- 2.6.18/sysroot-i586-pmmx-linux-gnu/usr/include/sys/syscall.h:32:27: error: bits/syscall.h: No such file or directory Does this directory exists on your host? /opt/OSELAS.Toolchain-1.1.0/i586-pmmx-linux-gnu/gcc-4.1.2-glibc-2.5-kernel-2.6.18/sysroot-i586-pmmx-linux-gnu/usr/include/bits Can you send me your logfile (should exists in the root directory of your project when you are trying to build it). And the logfile from the toolchain build. Maybe it could help to find the mistake in your environment. What kind of linux system do you use? Logfile(s) attached. I'm using Fedora Core 7 That file definitely exists - at least for other toolchains that I have built (even ones using ptxdist!) Juergen - perhaps you could put your actual toolchain on my FTP site? Yes. On the way... Thanks, I'll try this tomorrow and see if this works. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Testing 1.0.1
Juergen Beisert wrote: Gary, On Friday 02 November 2007 14:27, Gary Thomas wrote: Better use the OSELAS.Toolchain-Project. It supports more recent toolchains, the crosstool part is outdated. I got started on this, but ran into some troubles. The GCC snapshot gcc-4.2-20070207 is no longer available, so I tried to build the tools using the released version of gcc-4.2.2. This went pretty well, until I tried to build busybox: /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.2.2-glibc-2.5-kern el-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32:27: error: bits/syscall.h: No such file or directory Hmm, GCC 4.2.2 in OSELAS.Toolchain-1.1.0? Did you select this version of gcc by your own? Perhaps you should start with GCC 4.1.2 from the OSELAS.Toolchain-1.1.0 project. Or wait for our next OSELAS.Toolchain release. This also should support GCC 4.2. As mentioned, I tried to select the configuration which uses gcc-4.2-20070207, but that is no longer available, so I tried to use the released version gcc-4.2.2 I'm trying 4.1.2 now. So, it looks like some pieces are missing. Any ideas? help? I guess GCC 4.2.2 misses some patches to work correctly in OSELAS.Toolchain-1.1.0. I don't see any patches that deal with these [missing] include files. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
Re: [ptxdist] Testing 1.0.1
Gary Thomas wrote: Juergen Beisert wrote: Gary, On Friday 02 November 2007 14:27, Gary Thomas wrote: Better use the OSELAS.Toolchain-Project. It supports more recent toolchains, the crosstool part is outdated. I got started on this, but ran into some troubles. The GCC snapshot gcc-4.2-20070207 is no longer available, so I tried to build the tools using the released version of gcc-4.2.2. This went pretty well, until I tried to build busybox: /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.2.2-glibc-2.5-kern el-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32:27: error: bits/syscall.h: No such file or directory Hmm, GCC 4.2.2 in OSELAS.Toolchain-1.1.0? Did you select this version of gcc by your own? Perhaps you should start with GCC 4.1.2 from the OSELAS.Toolchain-1.1.0 project. Or wait for our next OSELAS.Toolchain release. This also should support GCC 4.2. As mentioned, I tried to select the configuration which uses gcc-4.2-20070207, but that is no longer available, so I tried to use the released version gcc-4.2.2 I'm trying 4.1.2 now. Sadly, I get the same error. /opt/OSELAS.Toolchain-1.1.0/i586-unknown-linux-gnu/gcc-4.1.2-glibc-2.5-kernel-2.6.18/sysroot-i586-unknown-linux-gnu/usr/include/sys/syscall.h:32:27: error: bits/syscall.h: No such file or directory Has anyone successfully built an i586 toolchain and then used it to build ptxdist-1.0.1 (OSELAS.BSP-Pengutronix-GenericI586Glibc-3)? So, it looks like some pieces are missing. Any ideas? help? I guess GCC 4.2.2 misses some patches to work correctly in OSELAS.Toolchain-1.1.0. I don't see any patches that deal with these [missing] include files. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] Testing 1.0.1
I'm interested in testing 1.0.1, using a stand-alone PC as a WWW kiosk for an example. It's unclear to me all the steps I need to follow. I've downloaded the 1.0.1 release, along with the patches and I'm using the 1.0.0 projects (there is no 1.0.1 project set although the install notes said there would be). I also downloaded the CrossTool project (http://www.pengutronix.de/oselas/crosstool/download/OSELAS.Crosstool-1.0.1.tar.gz) Here are the steps I think I need to take: * Build a set of cross-tools (I know that for a standard PC as the target this isn't strictly necessary) * Configure my target - Basic, simple, stand-alone environment - Including X + firefox * Build * Deploy - Initially using an NFS root file system for testing I've downloaded all of the application notes. While these are useful, they don't quite give me enough to complete the task above. n.b. I've been using ptxdist since 0.6 days and deploy it on my embedded targets (PPC) all the time, but I have limited experience with the new version (1.0.1) and never anything as ambitious as what I've outlined above. Any help/pointers/guidance graciously accepted. Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] uClibc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone used the latest PTXdist with uClibc? If so, did you build the toolchain within the OSELAS paradigm? - -- - Gary Thomas | Consulting for the MLB Associates |Embedded world - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGgSD0maKbSsQGV8ARAsnLAJ9nZA29/U+SH8gZyf81Si4jvQeIgQCfc4dG peg4aCPKx+Ha7HztbEyn/dM= =rVG0 -END PGP SIGNATURE- -- ptxdist mailing list ptxdist@pengutronix.de
[ptxdist] pekwm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Using ptxdist-1.0.0, I've configured a system to use X Windows and 'pekwm'. It seems that the target install step of pekwm doesn't really do anything on the target (no config files, etc). Has anyone actually used this window manager? Are there any other choices available? Thanks - -- - Gary Thomas | Consulting for the MLB Associates |Embedded world - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGXEY3maKbSsQGV8ARAlghAJ0R6Yt7Sad6i7d++x5V7HParKMJsACfZbM7 EOF+f/pMOsu6trYXXrCyj3E= =XJJE -END PGP SIGNATURE- -- ptxdist mailing list ptxdist@pengutronix.de
