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
> 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
>> 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.
>> 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:
> void b();
> void a()
> and linker reports:
> Warning: Unresolved:
> 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:
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
from line 344 of
from line 8 of
from line 34 of test_all.py (run_tests)
from line 168 of test_all.py
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
// 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 acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk