Re: [Boost-build] [V2] Testing Tru64 toolset

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
>> 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
>> failure.
> 
> Ah, I see. The test is corrected.

Thanks.

> 
>>>   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:
> 
>    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 
/vol2/boost/src/boost-HEAD/tools/build/v2/test/../../jam_src/bin.osf/bjam 
-sBOOST_BUILD_PATH=/vol2/boost/src/boost-HEAD/tool
s/build/v2/test -d0 --quiet
         at line 384 of 
/vol2/boost/src/boost-HEAD/tools/build/v2/test/BoostBuild.py (fail_test)
         from line 344 of 
/vol2/boost/src/boost-HEAD/tools/build/v2/test/BoostBuild.py (run_build_system)
         from line 8 of 
/vol2/boost/src/boost-HEAD/tools/build/v2/test/dependency_test.py
         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 
declarations. (emptyfile)
// Dummy comment, supposed to suppress 'empty-file' warning from HP-CXX
--^

Set environmental variable 'DO_DIFF' to examine difference.
FAILED
--->%---

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

Markus