PTXdist - Frequently Asked Questions

Q: PTXdist does not support to generate some files in a way I need them. What can I do?

A: Everything PTXdist builds is controlled by "package rule files", which in fact are Makefiles (rules/*.make). If you modify such a file you can change it's behaviour in a way you need. It is generally no good idea to modify the generic package rule files installed by PTXdist, but it is always possible to copy one of them over into the rules/ directory of a project. Package rule files in the project will precede global rule files with the same name.

Q: How can I start with a clean project? "ptxdist menuconfig" complains about a missing ptxconfig file. Do I always need to clone an existing project?

A: No, you don't. But you need a ptxconfig file with at least one symbol: PTXCONF_CONFIGFILE_VERSION. Declare it with the version number your PTXdist states when you run "ptxdist --version". If it outputs for example "1.0.2", your "ptxconfig" file should contain this line:

PTXCONF_CONFIGFILE_VERSION="1.0.2"

That's all. If you run "ptxdist menuconfig" now, all other symbols get their default values.

Note: In order to get a working configuration, audit especially the "PTXdist Config, Architecture" sections and adapt them to your hardware platform.

Q: Download failed due to some sourceforge mirrors are not reachable. What shall I do?

A: Change to another mirror with "ptxdist setup".

Q: I don't understand how "ptxdist toolchain" works. I tried it like this:

$ ptxdist toolchain /opt/ptxdist-0.10.4/gcc-4.0.2-glibc-2.3.6/arm-softfloat-linux-gnu/bin

Or like this:

$ ptxdist toolchain /opt/ptxdist-0.10.4/gcc-4.0.2-glibc-2.3.6/arm-softfloat-linux-gnu/bin/arm-softfloat-linux-gnu-

In both cases ptxdist complains:

ptxdist: error: Compiler 'arm-softfloat-linux-gnu-gcc' not found.  Check PATH or
ptxdist: error: use 'ptxdist toolchain <path/to/toolchain>'.

A: Setting the toolchain is a per-project operation. This makes it possible to specify different toolchains for different projects, which is a good thing if you switch around between several projects often.

Q: How to extend the menu of a given ptxdist project? I mean that one that I get when running 'ptxdist menuconfig'. I want to add my own config options.

A:This topic is discussed in an Application Note.

Q: My kernel build fails. But I cannot detect the correct position, due to parallel building. How can I stop ptxdist to build in parallel?

A: Run ptxdist with the PARALLELMFLAGS variable set to -j1, which looks somehow like:

PARALLELMFLAGS=-j1 ptxdist go

Q: When I build my own application the compiler fails with "Compiler badness...". What does it mean?

A: It does mean the cross compiler has found some code that tries to include files from your host. This should never happen for makefiles which cope correctly with cross situations. Vanilla (upstream) gcc versions don't show this messages; it has been added to OSELAS.Toolchain() compilers in order to quickly find situations where the wrong header files are being included.

Q: I made my own rule file and now I get error messages like

my_project/rules/test.make:30: *** unterminated call to function `call': missing `)'.  Stop.

But line 30 only contains @$(call targetinfo, $@) and it seems all right. What does it mean?

A: Yes, this error message is confusing. But it usually only means that you should check the following (!) lines for missing backslashes (line separators).

Q: I got a message similar to Packet friesel is empty. not generating. What does it mean?

A: The 'ipkg' tool was advised to generate a new ipkg-packet, but the folder was empty. Sometime it means a typo in the package name when the install_copy macro was called. Ensure all these macros are using the same package name. Or did you disable a menuentry and now nothing will be installed?

Q: How do I download all required packages at once?

A: Run this command prior the build:

$ ptxdist make get

This starts to download all required packages in one run. It does nothing if the packets are already present in the source path. (run "ptxdist setup" first).

Q: I want to backup the source archives my PTXdist project relys on. How can I find out what packages my project requires to build?

A:First build your PTXDist project completely and then run the following command:

$ for i in `cat state/packetlist`; do copy <src/>$i <archive directory>; done;

It copies all archives from <src/> (where are your source archives stored) to <archive directory> which can be your backup media. Or do whatever you like with the filenames listed in file state/packetlist.

Q: I want to boot into the root/ directory in my project via NFS. It basically works, but after entering userspace, I get

Unable to open initial console.

What am I doing wrong?

A: PTXdist tries to do everything with user privilegues and wants to avoid to do things which can only be done by root. In order to get a working nfs bootable root filesystem, run

$ sudo cp -a /dev/{console,null} root/dev/

to copy the device nodes "console" and "null" over to your dev/ directory. Don't forget the "-a", or strange things will happen to your console.

Note that this is only necessary for the nfs case; if PTXdist builds images, "fakeroot" is being used in order to create the necessary device nodes.

Another option is to add a local rule file which creates root/dev/console and root/dev/null as files; This will at least make the boot process continue up to the point where a "tmpfs" is being mounted over dev/ and is populated by "udev".

Q: I did everything above but my target still cannot open the console. What else can be wrong?

A: You need a kernel based nfs server. Do not use the userspace nfs server.

A: Don't forget the no_root_squash option when exporting your root/ via nfs.
So your export line should look like this:

<whatever_to_export> <to_whom_ever_to_export>(rw,no_root_squash,sync)

For example:

/home/me/my_project/root *(rw,no_root_squash,sync)

Note: The no_root_squash option allows your target to be root also on your host. This is potentially a huge security hole.

A: Take care there is no space between the <to_whom_ever_to_export> argument and the left parenthesis! If there is one, the parser fails and ignores the arguments. In this case the NFS server will use the default settings for this exported directory. And the default settings contain root_squash. So the kernel cannot open a /dev/console owned by root.

Q: I want to build my project but always get a message like this:

ptxdist: error: Cannot check toolchain vendor. If this is all right,
ptxdist: error: leave 'check for specific toolchain vendor ' emtpy!

A: There could be more than one reason for such a message:

No toolchain available. The ptxdist toolchain path/to/toolchain/bin step was omitted.
No toolchain vendor information available but project's setup forces a specific one

Every PTXdist project forces a specific compiler defined by a prefix to the standard tool names. So PTXdist does not call gcc to compile something target related, it calls $(PTXCONF_GNU_TARGET)-gcc instead. The PTXCONF_GNU_TARGET variable is defined in project's ptxconfig file.
PTXdist uses this kind of toolnames in conjunction with project's .toolchain link to gain access to the toolchain itself and its vendor information. If one of these settings do not match, you will get the failure message above.

Q: I did some changes in my project configuration. Do I have to rebuild the whole project every time to make these changes valid?

A: PTXdist cannot detect if configuration changes need to rebuild something to make them valid. Only newly selected packages will be built whithin the next ptxdist go step.
To avoid cleaning the whole project and rebuild everything when configuration changes where made, you can clean only the package that belongs to the configuration changes. For example: If you change some settings in the busybox package, run a

$ ptxdist clean busybox; ptxdist go

to only reconfigure and rebuild the busybox package. If you change something in the root filesystem settings, run a

$ ptxdist clean rootfs; ptxdist go

to make these new settings valid.
Unfortunately its not easy to guess what menu entry belongs to the exact package name to clean and rebuild after a configure change. One way could be to take a look into the state/ directory. Search for a file name that seems to be the name of the package you just manipulated in the menu. The basename of these files are also the packages names you must use to clean them with the ptxdist command.

Another way to avoid cleaning and rebuilding after each change could be the drop command to PTXdist. With this command you can drop dedicated build stages and forcing PTXdist to do this stage and all the required following stages again. For example:

$ ptxdist drop busybox prepare

will start again with the prepare stage for the busybox without extracting it again when the next ptxdist go will be executed. This could save time while development process.

Q: To avoid building the OSELAS toolchain on each development host, I copied it to another machine. But on this machine I cannot build any BSP with this toolchain correctly. All applications on the target are failing to start due to missed libraries.

A: This happens when the toolchain was copied without regarding to retain links. There are archive programs around that convert links into real files. When you are using such programs to create a toolchain archive this toolchain will be broken after extracting it again.
Solution: Use archive programs that retain links as they are (tar for example).
Here an example for a broken toolchain:

$ ll `find . -name "libcrypt*"`
-rwxr-xr-x 1 mkl ptx 55K 2007-07-25 14:54 ./lib/libcrypt-2.5.so*
-rwxr-xr-x 1 mkl ptx 55K 2007-07-25 14:54 ./lib/libcrypt.so.1*
-rw-r--r-- 1 mkl ptx 63K 2007-07-25 14:54 ./usr/lib/libcrypt.a
-rw-r--r-- 1 mkl ptx 64K 2007-07-25 14:54 ./usr/lib/libcrypt_p.a
-rwxr-xr-x 1 mkl ptx 55K 2007-07-25 14:54 ./usr/lib/libcrypt.so*

And in contrast, this one is intact:

$ ll `find . -name "libcrypt*"`
-rwxr-xr-x 1 mkl ptx 55K 2007-11-03 13:30 ./lib/libcrypt-2.5.so*
lrwxrwxrwx 1 mkl ptx  15 2008-02-20 14:52 ./lib/libcrypt.so.1 -> libcrypt-2.5.so*
-rw-r--r-- 1 mkl ptx 63K 2007-11-03 13:30 ./usr/lib/libcrypt.a
-rw-r--r-- 1 mkl ptx 64K 2007-11-03 13:30 ./usr/lib/libcrypt_p.a
lrwxrwxrwx 1 mkl ptx  23 2008-02-20 14:52 ./usr/lib/libcrypt.so -> ../../lib/libcrypt.so.1*

Q: I followed the instructions how to integrate my own plain source project into ptxdist. But when I try to build it, I get:

extract: archive=/path/to/my/sources
extract: dest=/path/to/my/project/build-target
Unknown format, cannot extract!

But the path exists!

A: ptxdist interprets a file:// (two slashes) in the URL as a project related relative path. So it searches only in the current project for the given path. Only file:/// (three slashes) will force ptxdist to use the path as an absolute one.
This means: file://bla/blub will be used as ./bla/blub and file:///friesel/frasel as /friesel/frasel.

Q: ptxdist fails in various scripts on my Ubuntu based system

A: ptxdist uses /bin/sh in these scripts and expects a bash behind it.
But on Ubuntu a dash will be used as default. One possible solution to fix it: The link named /bin/sh should point to /bin/bash.
Next stable release of ptxdist-1 will hopefully use always /bin/bash instead. The current development version of ptxdist does not use /bin/sh anymore.

Q: I want to use more than one kernel revision in my BSP. How can I avoid maintaining one ptxconfig per kernel?

A: One solution could be to include the kernel revision into the name of the kernel config file. Instead of the default kernelconfig.target name you should use kernelconfig-<revision>.target. In the kernel config file menu entry you should enter kernelconfig-${PTXCONF_KERNEL_VERSION}.target.
Whenever you change the linux kernel Version menu entry now, this will ensure using a different kernel config file, too.

Q: I'm running ptxdist in a virtual machine and all provided test scripts are failing while automated boardsetup

A: We have seen this behaviour on machines that runs Windows and as a guest a Linux system. One of these systems eats up characters sent through the serial line. This ptxdist feature can currently only be used on Linux only systems.

Q: I'm trying to use a JAVA based package in ptxdist. But compiling fails badly. Does it ever work at Pengutronix?

A: This kind of packages only build correctly when an original SUN VM SDK is used. Run ptxdist setup and point the Java SDK menu entry to the installation path of your SUN JAVA SDK.

Q: I made a new project and everythings seems fine. But when I start my target with the root filesystem generated by ptxdist, it fails with:

cannot run '/etc/init.d/rcS': No such file or directory

A: The error message is confusing. But this script needs /bin/sh to run. Most of the time this message occures when /bin/sh does not exists. Did you enable it in your busybox configuration?