Boost logo

Boost-Build :

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-02-13 08:20:17

Vladimir Prus wrote:

>> 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
> extension.
> BTW, I wonder if "-x c" is present, too?

I knew you would ask. ;-) But according to the man page and confirmed by my
experiments it's only present in the Linux version of cxx and not in the
Tru64 version.

>>> use_requirements
>> This failure is caused by the fact that the test creates a library called
>> and the linker later confuses this library with the system C
>> library. Renaming the generated to something else would fix the
>> failure.
> 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 consists of just one file:
> void b();
> void a()
> {
> b();
> }
> and linker reports:
> Warning: Unresolved:
> b(void)
> tru64.compile.c++ bin/tru64/debug/b.o
> 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.

Here is an excerpt from the ld manual:

-expect_unresolved pattern
Ignore any unresolved symbols that match pattern. Such symbols are not
displayed and are not treated as errors or warnings. You can enter this
option multiple times on a command line. The patterns use shell wild-
card characters (?, *, [, ]). The wildcard characters must be properly
quoted to prevent them from being expanded by the shell. For more
information, see sh(1).

I added -expect_unresolved * to the command line generated by the link.dll
action, the test now passes. The change is committed.

> 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.

I think it's OK to add it when linking dynamic libraries.

I reran the full regression tests and there is only one failure left now.

FAILED test of
s/build/v2/test -d0 --quiet
         at line 384 of
/vol2/boost/src/boost-HEAD/tools/build/v2/test/ (fail_test)
         from line 344 of
/vol2/boost/src/boost-HEAD/tools/build/v2/test/ (run_build_system)
         from line 8 of
         from line 34 of (run_tests)
         from line 168 of

in directory: /cluster/members/member0/tmp/tmpggbq_pdependency_test
    : STDOUT ===================

Expected STDERR ==========

Actual STDERR ============
cc: Warning: src1/z.h, line 1: Source file does not contain any
declarations. (emptyfile)
// Dummy comment, supposed to suppress 'empty-file' warning from HP-CXX

Set environmental variable 'DO_DIFF' to examine difference.

Seems like you need some actual declaration in there to make the warning go


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at