From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-02-13 07:34:54
On Monday 13 February 2006 15:17, Markus Schöpflin wrote:
> Vladimir Prus wrote:
> Due to your debugging tips I managed to find the cause for some of the
> > There are some failures that are not obvious for me. Those are:
> > generators_test
> This one was caused by the fact that cxx silently ignores any files it
> doesn't recognize as C++ files. The source file for e.o doesn't have any
> extension, therefore no object file was created.
Or, rather, it has ".target_cpp" extension, which is not recognized by the
> I added an option (-x cxx) to the toolset file to force the compiler to
> treat any given file as C++ source file, but other compilers will have the
> same problem too, I think. Maybe you should change the test the a file with
> the proper extension is generated.
It might be good to leave the test as is, that way we'll be sure that
appopriate option is passed, in case uses decides to use non-standard
BTW, I wonder if "-x c" is present, too?
> > use_requirements
> This failure is caused by the fact that the test creates a library called
> libc.so and the linker later confuses this library with the system C
> library. Renaming the generated libc.so to something else would fix the
Ah, I see. The test is corrected.
> > library_order
> For this one I have no idea if anything is wrong at all. Maybe you can
> tell, I have the log file attached.
The liba.so consists of just one file:
and linker reports:
Because the 'b' symbol is not found. So, the linker differs in behaviour from
GNU linker, that allows shared library to contain unresolved references and
does not produce even a warning.
This leaves two questions:
1. Is there an option to suppress the warning? I saw some "-expect_unresolved"
options in V1 toolset file.
2. Should such option be always used, or only for this test? I'd prefer to
always used it, but I'm so accustomed to GNU behaviour that my opinion does
not matters much.
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