CrossCompiling Portability

[GoogleCodeExporter]

Suggest modifying the "ByteOrder.hpp" file located /RCF/util/Platform/Machine/

To check for ARM processor.  In my case it was Little Endian.  Thus added:
#elif defined(__arm__)
#include "x86/ByteOrder.hpp"

I inserted this after line 26 and before the "#else   #include
"UnknownMachine/ByteOrder.hpp"

otherwise it compiles and runs on an ARM processor with a linux kernel.

Original issue reported on code.google.com by ian.harr...@gmail.com on 23 Jan 2009 at 7:53

[GoogleCodeExporter]

Thanks, I've incorporated this change into RCF 1.1.

Original comment by jarl.lin...@gmail.com on 4 Feb 2009 at 6:58

[GoogleCodeExporter]

Jarl... are you planning on making 1.1 a dynamic/static library to link against?

Original comment by ian.harr...@gmail.com on 12 Feb 2009 at 6:46

[GoogleCodeExporter]

So far I haven't included any binaries at all in RCF distributions, because 
generally it's easier (and safer) for users to build their own. On Windows you 
can 
build a DLL by setting your build settings to produce a DLL, including RCF.cpp, 
and 
defining RCF_BUILD_DLL, to export all the relevant RCF functions and classes.

I haven't tested it in non-Windows envrionments, but in theory if you are using 
gcc 
4.x, with RCF_BUILD_DLL defined, RCF classes will be exported using gcc's

__attribute__ ((visibility("default")))

 extension.

I'd be happy to hear about whether it works or not, and if anything needs to be 
fixed there.

Original comment by jarl.lin...@gmail.com on 12 Feb 2009 at 10:54

[GoogleCodeExporter]

Attached is my console output when trying to compile it on linux as a library 
[with
Debug info and un-optimized].

Preprocessor Settings:
-DRCF_USE_BOOST_ASIO 
-DRCF_USE_BOOST_READ_WIRE_MUTEX 
-DRCF_USE_BOOST_THREADS 
-DBOOST_ASIO_HAS_LOCAL_SOCKETS 
-DRCF_BUILD_DLL

Include Paths:
-I/Libraries/IA32/include 
-I/Libraries/IA32/include/boost-1_36 
-I/home/iharrold/Libraries/tar/RCF/RCF-1.0_IA32/include 
-I/home/iharrold/Libraries/tar/RCF/RCF-1.0_IA32/src 
-I/home/iharrold/Libraries/tar/RCF/RCF-1.0_IA32/src/RCF 
-I/home/iharrold/Libraries/tar/RCF/RCF-1.0_IA32/src/SF

CPPFlags:
-O0 
-g3 
-Wall 
-c 
-fmessage-length=0

As you can see in the log file I get an error on line 120 of 
/include/RCF/Exception.hpp.

I simply copied the RCF.cpp into my project and then tried to compile it.  It 
is the
only file in the project and all other items are linked or pointed to in the 
Make file.

g++ -v yields:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc
--enable-mpfr --enable-targets=all --enable-checking=release 
--build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)

Any help would be greatly appreciated.  It would greatly reduce my compile time 
if I
can create a shared/static library of RCF as well as reduce my compiled object 
size.

Original comment by ian.harr...@gmail.com on 22 Feb 2009 at 6:04

Attachments:

• [RCFLib error.txt](https://storage.googleapis.com/google-code-attachments/rcf-cpp/issue-9/comment-4/RCFLib error.txt)
• makefile
• objects.mk
• sources.mk
• subdir.mk

[GoogleCodeExporter]

RCF 1.0 was not tested as a shared library on Unix platforms, and in fact there 
is a 
typo in the code that is causing the compiler errors. You should be able to 
build it 
as a static library without any problems. If you want to build a shared library 
anyway, with gcc, I would suggest locating the following code in Export.hpp:

    #if defined(__GNUC__) && __GNUC >= 4 
        #define RCF_EXPORT __attribute__ ((visibility("default")))
    #else

, and replacing it with 

    #if defined(__GNUC__)
        #define RCF_EXPORT
    #else

That should get you past the compiler errors. If the linker complains, you may 
need 
to use the -fPIC compiler option as well.

I've fixed this up in 1.1, to support __attribute__((visibility())) in gcc 4.x .

Original comment by jarl.lin...@gmail.com on 26 Feb 2009 at 11:08

[GoogleCodeExporter]

Well I got it to create a dynamic and static library with your suggestion.  I 
just
haven't tested yet.  I'll know more shortly.  "nm" seems to interpret them 
fine. 
Thanks for the reply.

Original comment by ian.harr...@gmail.com on 26 Feb 2009 at 8:17

[GoogleCodeExporter]

Original comment by jarl.lin...@gmail.com on 28 May 2009 at 1:47

• Changed state: Closed
• Added labels: Milestone-1.1