[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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/,
provided
by libc6-dev-powerpc-cross package.

Is the file there?

Have you downloaded libc6-dev-powerpc-cross package, or built it
yourself
with dpkg-cross -b? Maybe you've built it with non-default path
configuration? (I guess dpkg-cross should name created package
differently
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
/etc/dpkg/cross-compile contains:


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 to make it different unless toolchain is able to handle that) - this may be fixed
immidiatly

- - the cause of probalem was that user config overrides completely system conffile. Raphael, what do you think about proposed patch? it is safe? Or probably we should postpone better config handling until dpkg-cross 2.0,
where such functionality is planned anyway?

- - dependences can't track situation when different -arch-cross packages use different paths. Looks that any combination of -arch-cross packages with
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 current package and in dependent packages are the same, make installation fail if
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 /usr/powerpc-linux,
and if someone needs a package with files elsewhere, that package will
have different (probably somewhat long) name
Second solution looks better for me.

Comments?

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 & LIB=~/lib.

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.

Jack

Nikita



Reply to: