Jan Kiszka wrote:
Philippe Gerum wrote:

Jan Kiszka wrote:


Philippe Gerum wrote:


...
Good idea. Just implemented as described, now in the CVS. Thanks for the
hint. Additional testing welcome.

PS: *.mod files contents refer to the build directory, so I guess that
such information would not be useful for setups that only provide the
installed binaries (and not the initial build dir). But still, I have
nonetheless exported the symbols to $exec_prefix/symbols as proposed.



That's good news. I started playing a bit with it and have two remarks
so far:

1. As it seems that we will no longer be able to build *modules* against
RTAI just by using the files from the installation directory, I see no


Why? I mean, I don't see the difference wrt the previous situation. We
can still build modules only using the installed stuff and the kernel
tree in any case, we just get the Kbuild warnings unless we have the
symbols available from the initial fusion build dir. I've just tried
that after having removed the build dir, and it's ok.


I thought the PPC issues were severer than just warnings. Anyway,
reasonable development is not possible with all those warnings around
again, and that's what made me draw the line.



The PPC issues were caused by the version information being squeezed by the old kludge; now they aren't anymore, so PPC should be ok like it's now ok for the Itanium port, which happened to have the same problem. IOW, the new approach you proposed actually solved the matter in the same move.

Regarding the warnings, the only way to get rid of them is to actually have access to the dependencies pointed at by the .mod files, but this is not a new constraint brought by the symbol directory scheme, this has always been imposed by the Kbuild system.

--

Philippe.

Reply via email to