Subject: Re: [Boost-build] cross compiling linux boost libraries
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-07-12 08:45:07
On Monday 12 July 2010 14:46:37 Moritz Hassert wrote:
> Am Montag, 12. Juli 2010, um 09:48:08 schrieb Vladimir Prus:
> > > > [...]
> > >
> > > The odd thing with boost-build is that it sometimes does not bail out
> > > with an error when it can't fullfill your exact request. Instead it
> > > tries to something that it considers 'a good alternative'. At least
> > > thats my experience.
> > >
> > > In your case the toolset 'gcc-mips' is most likely not known to
> > > boost-build. That is, it does not have a gcc with version 'mips'
> > > configured. But instead of complaining it tries to auto-configure that
> > > compiler. And if it cannot find an executable 'g++-mips' or something
> > > like that it will fall back to the default command for toolset gcc,
> > > which is of cause 'g++'.
> > That's an outright bug, I guess. Care to file it in the tracker?
> I'm suprised you call it a bug. I always thought it's one oft those places
> where the "do the right thing" - policy of boost.build hits you in the head.
> (I think I remember reading somewhere you talking about that policy)
> Using the default gcc sure is a sane default for the average boost user who
> "just wants to compile boost". But as in many cornerplaces of boost.build it
> seems no one considered such "strange" things as cross-compiling. And I would
> have never considered it a bug, as the gcc.jam code (as far as I understand)
> explicitly uses a default g++ for cases where the tool is not found.
Actually -- not when it's not found, but rather when it's not specified. The
bug, IMO, is that given toolset=gcc-foo when 'foo' is not a known version of
gcc, we try to configure 'gcc-foo', even though in 99% in cases user add 'foo'
for some reason, and there's no code to respect whatever request user is making.
> Just another example: As far as I understand from googling and my experience,
> the target alternative selection depending on feature properties selects the
> "most fitting" alternative even if that one is not fitting at all. It just has
> to be "more fitting" than all the others. I think I remember reading that this
> is by design.
I think it's the other way around. All properties in a target alternative must
match exactly. It's only for a target with a single alternative, requirements do override
> Of cause, an end user compiling software (boost) for his local machine doesn't
> really care if libs are linked static or dynamic as long as his program runs
> fine. But as a developer I want to specify exactly what is to be done and I
> want it to be done exactly that way or not at all. I like errors. I even
> switch on warnigs when compiling :)
> I even managed have a <build>no target to get happily built into a subdir
> .../build-no/... :(
> Why? I guess because it was a lib target and there was a exe target (without
> <build>no) depending on it. As there where no other targets of that name it
> was the best alternative and "had to be build".
Well, this is probably a bug, too.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk