Bipod setup

There are two problems with comp I am am aware of, oneis realated to 2.4.x, the other one not:

problem A
This is related to EMC 2.4.x and was not there in 2.3.x (as far as I know).
At least one symbol (HAL_SUCCESS) was removed from a header file. This is the reason why you cannot compile the original dualbipod.c.
With some simple modifications, dualbipod.c can be compiled now with comp 2.4.x
This mods has been discussed here a while ago (see #4398 in this thread)

problem B
This is not related to a specicific version and has been always there.
comp creates warnings like this:
WARNING: "hal_init" [/tmp/tmpFFENKL/dualbipod.ko] undefined!
These warnings has been ignored by me and most other people, because they are "only" warnings, and the result is ok.
Wolfgang (Schnitti) is discussing methods how to avoid the warnings and created an entry in the bug-list of EMC

hope this makes things more clear and removes confusion

Gerd

I'm talking about comp to create hal components. In this case the component is a non-trivial kinematic module.

Gerd

BigJohnT wrote:

I had no idea that comp created kinematics modules as well as components.

John

Hi John,

exactly that is the point. comp can create kinematics modules and components.

I took a look at kbuild system documentation. There is a part in there, which in my opinion belongs to this discussion.

We have this situation

rtai modules in /usr/realtime-2.6.32-122-rtai/modules
emc modules in /usr/realtime-2.6.32-122-rtai/modules/emc2

Modules.symvers only in rtai path

Should do the job.

+++++
copy from
www.mjmwired.net/kernel/Documentation/kbuild/modules.txt
+++++

7.2 Symbols and external modules

When building an external module, the build system needs access to
the symbols from the kernel to check if all external symbols are
defined. This is done in the MODPOST step and to obtain all
symbols, modpost reads Module.symvers from the kernel.
If a Module.symvers file is present in the directory where
the external module is being built, this file will be read too.
During the MODPOST step, a new Module.symvers file will be written
containing all exported symbols that were not defined in the kernel.

--- 7.3 Symbols from another external module

Sometimes, an external module uses exported symbols from another
external module. Kbuild needs to have full knowledge on all symbols
to avoid spitting out warnings about undefined symbols.
Three solutions exist to let kbuild know all symbols of more than
one external module.
The method with a top-level kbuild file is recommended but may be
impractical in certain situations.

Use a top-level Kbuild file
If you have two modules: 'foo' and 'bar', and 'foo' needs
symbols from 'bar', then one can use a common top-level kbuild
file so both modules are compiled in same build.

Consider following directory layout:
./foo/ <= contains the foo module
./bar/ <= contains the bar module
The top-level Kbuild file would then look like:

#./Kbuild: (this file may also be named Makefile)
obj-y := foo/ bar/

Executing:
make -C $KDIR M=`pwd`

will then do the expected and compile both modules with full
knowledge on symbols from both modules.

Use an extra Module.symvers file
When an external module is built, a Module.symvers file is
generated containing all exported symbols which are not
defined in the kernel.
To get access to symbols from module 'bar', one can copy the
Module.symvers file from the compilation of the 'bar' module
to the directory where the 'foo' module is built.
During the module build, kbuild will read the Module.symvers
file in the directory of the external module and when the
build is finished, a new Module.symvers file is created
containing the sum of all symbols defined and not part of the
kernel.

Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
If it is impractical to copy Module.symvers from another
module, you can assign a space separated list of files to
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
loaded by modpost during the initialisation of its symbol
tables.

Hi there,

I put my dualbipod.ko module file in Gerd's googlecode page:

code.google.com/p/emc2hotwinch/source/br...#svn/trunk/kinematic

dualbipod-2.6.32-rtai.ko

Please rename to dualbipod.ko before you copy and use it.

Otherwise I had to overwrite the old Module.

Wolfgang

Hi there,

usage of fresh compiled dualbipod.ko under 2.4.5 fails, vermagic of module and running kernel does not match error.

To get this off:

Edit kernel Makefile under /usr/src/linux-headers-2.6.32-122-rtai/Makefile
remove EXTRAVERSION from debian maintainer
Add EXTRAVERSION = -122-rtai

Run make as root with no arguments in /usr/src/linux-headers-2.6.32-122-rtai

run sudo comp --install dualbipod.c

Works!

Submitted in Bugtracker too.

Hi,

just tested it on my production/real machine. Seems, that is dedicated to a weak installation.

Will observe it.

Hi,

I can confirm, that compilation on a fresh installed system will work with the mentioned warnings.

And as a personal experience, it is in fact faster to save your settings and set up a new system and copy settings back.

Wolfgang