Re: cross-gcc status
On Oct 18, 2004, at 9:54 PM, Nikita V. Youshchenko wrote:
Thanks very much for your help, Nikita!
On Oct 14, 2004, at 9:45 PM, Nikita V. Youshchenko wrote:
The mentioned 'signal.h' should be in /usr/powerpc-linux/include/,
by libc6-dev-powerpc-cross package.
Is the file there?
Have you downloaded libc6-dev-powerpc-cross package, or built it
with dpkg-cross -b? Maybe you've built it with non-default path
configuration? (I guess dpkg-cross should name created package
if non-default paths are used...)
Ah ha - I built libc6-dev-powerpc-cross myself, using dpkg-cross 1.9,
but it put everything in /usr/local/powerpc-linux, even though
crossbase = /usr
dpkg-cross used to put everything in /usr/powerpc-linux - however I've
since created a private configuration file!
I expected dpkg-cross to read both configuration files, overriding
options in /etc/dpkg/cross-compile with options in my private
configuration. This is not the case, & it wasn't clear that it is not
until I groked the source.
I see several issues here.
- - bad default for crossbase (it *should* be /usr, there is no point
it different unless toolchain is able to handle that) - this may be
- - the cause of probalem was that user config overrides completely
conffile. Raphael, what do you think about proposed patch? it is safe?
probably we should postpone better config handling until dpkg-cross
where such functionality is planned anyway?
- - dependences can't track situation when different -arch-cross
different paths. Looks that any combination of -arch-cross packages
different paths is broken if installed in the same system. I see two
possible solutions here:
*) in postinst of -arch-cross packages, ensure that paths in the
package and in dependent packages are the same, make installation fail
they are not; add path check code to anything that use -arch-cross
packages (e.g. to cross-gcc building scripts).
*) if paths are non-default, encode path information info package name
suffix; so -powerpc-cross will always have files under
and if someone needs a package with files elsewhere, that package will
have different (probably somewhat long) name
Second solution looks better for me.
FWIW, I've always wished dpkg supported relative paths; for instance
$BIN/foo or $LIB/bar.1.so
One reason is so non-root users could use apt, by setting BIN=~/bin &
Another reason is so source packages could be packaged as ordinary
packages. Currently, a big difference between source packages &
ordinary packages is that a source package's contents are relative to
where it gets unpacked.
Why packaging source packages as ordinary packages would be great is
another discussion; maybe happening somewhere else? But just for
instance, a source package could declare dependancies on both ordinary
packages (like build-depends currently do) & on other source packages
(like kernel-patch-powerpc-2.6.8 currently does on kernel-tree-2.6.8,
or cyrus-sasl2-mit-src & cyrus-sasl2-heimdal-src could on
cyrus-sasl2-common-src). "aptitude update" could update one's source
packages, the way apt-src tries to. Packaging source packages as
ordinary packages could reduce the complexity of dpkg / apt by half; no
more build-deps, deb-src sources, dpkg-scansources, etc.
Obviously, support for relative paths would require the kind of path
sensitive dependancy checking you describe.
General dpkg support for relative paths may be lots more ambitious than
the solutions you propose, but for dpkg-cross, it would mean paths like
$CROSSINC/signal.h actually in packages. libc6-dev-powerpc-cross's
reverse dependancies might then declare something like
"libc6-dev-powerpc-cross (CROSSINC = /usr/powerpc-linux/include)".
Since $CROSSINC would be resolved when packages were installed, instead
of when they were built, one package could support different
configurations of $CROSSINC, $CROSSBASE, etc.