Re: Building typelib + dyncall with clang

On Mon, Dec 3, 2012 at 10:22 PM, Peter Soetens <[email protected]> wrote:
> Hi,
>
> I tried to build typelib with clang, but the dyncall-0.6 ruby bindings
> contain gcc specific assembly code.
>
> In dyncall-0.7, this has been fixed. I did a quick test, and both
> typelib + dyncall 0.7 can be compiled with clang/clang++. However, the
> typelib test suite fails:
>
> $ ./typelib_testsuite
> Running 42 test cases...
> unknown location(0): fatal error in "test_repositories_merge":
> std::runtime_error: plugin not found
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/clang/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/test/test_registry.cc(163):
> last checkpoint
> unknown location(0): fatal error in "test_csv": std::runtime_error:
> plugin not found
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/clang/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/test/test_display.cc(33):
> last checkpoint
> unknown location(0): fatal error in "test_tlb_idempotent":
> std::runtime_error: plugin not found
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/clang/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/test/test_display.cc(33):
> last checkpoint
> unknown location(0): fatal error in "test_tlb_import":
> std::runtime_error: plugin not found
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/clang/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/test/test_display.cc(33):
> last checkpoint
> unknown location(0): fatal error in "test_equality": memory access
> violation at address: 0x00000010: no mapping at fault address
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/clang/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/test/test_model.cc(138):
> last checkpoint
>
> *** 5 failures detected in test suite "typelib"
>
> While the toolchain built with gcc + dyncall-0.7 only fails with:
>
> $ ./typelib_testsuite
> Running 42 test cases...
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/gcc/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/test/test_marshalling.cc(93):
> fatal error in "test_marshalling_simple": critical check -1 ==
> memcmp(&a, &reloaded, sizeof(A)) failed [-1 != -256]
>
> *** 1 failure detected in test suite "typelib"
>
> So this seems more related to clang than to upgrading to dyncall-0.7.
> Also note that I had to set 'CC=clang' as environment variable, since
> the dyncall build detects its own compiler and does not pickup the one
> from cmake/typelib.

I pushed the patch in attachment to typelib. Since 0.6 can only be
compiled with gcc, I forced gcc when building dynlib (will break
cross-compilation though). This could be removed once 0.7 is used and
the regressions are fixed.

The end result is that the complete toolchain now builds with clang++
3.1, but not with TAO.

>
> BTW, there's also a pretty serious warning here:
>
> [ 19%] Building CXX object typelib/CMakeFiles/typeLib.dir/pluginmanager.o
> /home/kaltan/vbox/hudson/jobs/bootstrap-toolchain/workspace/CORBA_IMPL/TAO/Compiler/clang/TARGET/gnulinux/arch/amd64/branch/toolchain-2.5/orocos-toolchain/typelib/typelib/pluginmanager.cc:66:9:
> warning: delete called on 'Typelib::TypeDefinitionPlugin' that is
> abstract
>       but has non-virtual destructor [-Wdelete-non-virtual-dtor]
>         delete *it;
>         ^
> 1 warning generated.
>
> which should be fixed by making the destructor virtual in
> Typelib::TypeDefinitionPlugin

Looks like dead class, should be fixed or removed ?

Peter

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

From b60abb629896346ac060a8beec44142c22475697 Mon Sep 17 00:00:00 2001
From: Peter Soetens <[email protected]>
Date: Mon, 17 Dec 2012 00:50:54 +0100
Subject: [PATCH] dyncall: forcibly compile with gcc

Dyncall 0.6 contains gcc specific assembler code.
Upgrading to 0.7 fixed that but caused other regressions
in the typelib unit tests.

Signed-off-by: Peter Soetens <[email protected]>
---
 bindings/ruby/CMakeLists.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bindings/ruby/CMakeLists.txt b/bindings/ruby/CMakeLists.txt
index eae9714..a670464 100644
--- a/bindings/ruby/CMakeLists.txt
+++ b/bindings/ruby/CMakeLists.txt
@@ -29,7 +29,7 @@ IF(ENABLE_DYNCALL)
         DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/dyncall-0.6.tar.gz)
 
     ADD_CUSTOM_COMMAND(OUTPUT ${DYNCALL_LIBRARIES}
-        COMMAND $(MAKE) -j1 "CFLAGS=-O3 -fPIC"
+        COMMAND $(MAKE) -j1 "CFLAGS=-O3 -fPIC" "CC=gcc"
         COMMAND $(MAKE) -j1 install
         DEPENDS ${DYNCALL_SOURCE_DIR}/ConfigVars
         WORKING_DIRECTORY ${DYNCALL_SOURCE_DIR})
-- 
1.7.9.5