Home Help Center

Building IceE-trans 1.1.0 with customized g++ based on version g++3.1

Hello,

I am trying to rebuild IceE-trans 1.1.0 with customized g++ based on g++ version 3.1.
My final mission is to port IceE to an i686 board.
Well, I have made change in /config/Make.rules.Linux:
CXX = mn-linux-g++
&
ifeq ($(CXX), mn-linux-g++)

and in /config/Make.rules
CPPFLAGS = -I$(includedir) -I$(MAKETOP)/usr/include -L$(MAKETOP)/usr/lib $(STLPORT_FLAGS)

I run make, and the error seems to happen in ConvertUTF.cpp and its header includes, as shown below. Based on the Install.Linux readme, I knew that IceE require at least gcc 3.2, so I am acquire for confirmation if a customized g++ based on version 3.1 cannot be used to rebuild IceE...

Comments

  • syseekersyseeker Member
    error truncated, due to 10k character limit....

    making all in src
    make[1]: Entering directory `/root/usr/IceE-trans-1.1.0/src'
    making all in IceUtil
    make[2]: Entering directory `/root/usr/IceE-trans-1.1.0/src/IceUtil'
    mn10300-linux-g++ -c -I../../include -I/root/usr/include -L/root/usr/lib -DICE_UTIL_API_EXPORTS -I.. -ftemplate-depth-128 -Wall -D_REENTRANT -O3 -DNDEBUG ConvertUTF.cpp
    In file included from ../IceUtil/ConvertUTF.h:35,
    from ConvertUTF.cpp:53:
    ../../include/IceUtil/Unicode.h:81: syntax error before `&' token
    ../../include/IceUtil/Unicode.h:82: syntax error before `(' token
    ../../include/IceUtil/Unicode.h:116: syntax error before `*' token
    ../../include/IceUtil/Unicode.h:119: syntax error before `wchar_t'
    ../../include/IceUtil/Unicode.h:123: syntax error before `*' token
    ../../include/IceUtil/Unicode.h:127: syntax error before `*' token
    ../../include/IceUtil/Unicode.h:138: syntax error before `{' token
    ../../include/IceUtil/Unicode.h:142: virtual outside class declaration
    ../../include/IceUtil/Unicode.h:142: non-member function `const std::string
    IceUtil::ice_name()' cannot have `const' method qualifier
    ../../include/IceUtil/Unicode.h:143: virtual outside class declaration
    ../../include/IceUtil/Unicode.h:143: non-member function `void
    IceUtil::ice_print(std::ostream&)' cannot have `const' method qualifier
    ../../include/IceUtil/Unicode.h:144: syntax error before `*' token
    ../../include/IceUtil/Unicode.h:145: virtual outside class declaration
    ../../include/IceUtil/Unicode.h:145: non-member function `void
    IceUtil::ice_throw()' cannot have `const' method qualifier
    ../../include/IceUtil/Unicode.h:147: syntax error before `)' token
    ../../include/IceUtil/Unicode.h:154: syntax error before `}' token
    In file included from ConvertUTF.cpp:53:
    ../IceUtil/ConvertUTF.h:122: syntax error before `*' token
    ../IceUtil/ConvertUTF.h:126: syntax error before `*' token
    ../IceUtil/ConvertUTF.h:130: syntax error before `*' token
    ../IceUtil/ConvertUTF.h:134: syntax error before `*' token
    ConvertUTF.cpp:64: syntax error before `=' token
    ConvertUTF.cpp:65: syntax error before `=' token
    ConvertUTF.cpp:100: syntax error before `[' token
    ConvertUTF.cpp:110: syntax error before `[' token
    ConvertUTF.cpp:125: syntax error before `*' token
    ConvertUTF.cpp:128: syntax error before `*' token
    ConvertUTF.cpp:129: syntax error before `*' token
    ConvertUTF.cpp:133: syntax error before `=' token
    ConvertUTF.cpp:134: syntax error before `=' token
    ConvertUTF.cpp:135: syntax error before `*' token
    ConvertUTF.cpp:136: ISO C++ forbids declaration of `ch' with no type
    ConvertUTF.cpp:136: `source' was not declared in this scope
    ConvertUTF.cpp:138: syntax error before `if'
    ConvertUTF.cpp:149: ISO C++ forbids declaration of `result' with no type
    ConvertUTF.cpp:149: `sourceIllegal' was not declared in this scope
    ConvertUTF.cpp:150: syntax error before `break'
    ConvertUTF.cpp:154: ISO C++ forbids declaration of `result' with no type
    ConvertUTF.cpp:154: redefinition of `int result'
    ConvertUTF.cpp:149: `int result' previously defined here
    ConvertUTF.cpp:154: `sourceExhausted' was not declared in this scope
    ConvertUTF.cpp:155: syntax error before `break'
    ConvertUTF.cpp:161: ISO C++ forbids declaration of `result' with no type
    ConvertUTF.cpp:161: redefinition of `int result'
    ConvertUTF.cpp:154: `int result' previously defined here
    ConvertUTF.cpp:161: `sourceIllegal' was not declared in this scope
    ConvertUTF.cpp:162: syntax error before `break'
    ConvertUTF.cpp:171: ISO C++ forbids declaration of `ch' with no type
    ConvertUTF.cpp:171: `UTF32' was not declared in this scope
    ConvertUTF.cpp:171: syntax error before numeric constant
    ConvertUTF.cpp:174: syntax error before `+=' token
    ConvertUTF.cpp:177: syntax error before `-=' token
    ConvertUTF.cpp:177: ISO C++ forbids declaration of `result' with no type
    ConvertUTF.cpp:177: redefinition of `int result'
    ConvertUTF.cpp:161: `int result' previously defined here
    ConvertUTF.cpp:177: `targetExhausted' was not declared in this scope
    ConvertUTF.cpp:177: syntax error before `break'
    ConvertUTF.cpp:180: syntax error before `>>=' token
    ConvertUTF.cpp:181: syntax error before `>>=' token
    ConvertUTF.cpp:182: syntax error before `>>=' token
    ConvertUTF.cpp:185: syntax error before `+=' token
    ConvertUTF.cpp:187: ISO C++ forbids declaration of `sourceStart' with no type
    ConvertUTF.cpp:187: `source' was not declared in this scope
    ConvertUTF.cpp:188: ISO C++ forbids declaration of `targetStart' with no type
    ConvertUTF.cpp:188: `target' was not declared in this scope
    ConvertUTF.cpp:189: syntax error before `return'
    ConvertUTF.cpp:205: syntax error before `(' token
    ConvertUTF.cpp:207: syntax error before `*' token
    ConvertUTF.cpp:236: syntax error before `*' token
    ConvertUTF.cpp:247: syntax error before `*' token
    ConvertUTF.cpp:250: syntax error before `*' token
    ConvertUTF.cpp:251: syntax error before `*' token
    ConvertUTF.cpp:254: `trailingBytesForUTF8' was not declared in this scope
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    It looks like your standard C++ library doesn't support std::wstring. To workaround this issue, you could try to build the Ice-E translator with a compiler that supports std::wstring or if it's not possible, you could simply disable the compilation of the ConvertUTF.cpp and Unicode.cpp files in IceE-trans-1.1.0/src/IceUtil/Makefile. These 2 files are actually not required to build the translator.

    Let us know if you need more information!

    Cheers,
    Benoit.
  • syseekersyseeker Member
    Hi Benoit,

    I managed to compile by commenting out Unicode.o, ConvertUTF.o, StringUtil.o and Time.o. For the first 3 cpp files, it's all due to the same problem. However, for Time.o, and later on in ../Slice/Makefile Grammar.o, I faced a problem with Int64 ambiguity, somehow customized g++ compiler does not match Int64 to long int, is there anyway to work around with this?

    I tried Grammar.o but failed because Parser.o need it. Below is error for Grammar.cpp compilation

    Grammar.y: In function `int slice_parse()':
    Grammar.y:1556: ambiguous overload for `std::ostringstream& << Int64&' operator
    /usr/local/mn10300-linux/include/g++-v3/bits/ostream.tcc:137: candidates are:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(long int) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/ostream.tcc:167:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(long unsigned int) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/ostream.tcc:115:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(bool) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:100:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(short int) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:111:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(short unsigned int) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:115:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(int) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:126:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(unsigned int) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/ostream.tcc:241:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(double) [with _CharT = char, _Traits =
    std::char_traits<char>]
  • syseekersyseeker Member
    Strange... the Forum detect 15 images attached in my post, because of ":o" ...Below is the separated error code...

    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:141:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(float) [with _CharT = char, _Traits =
    std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/ostream.tcc:263:
    std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
    _Traits>::operator<<(long double) [with _CharT = char, _Traits =
    std::char_traits<char>]

    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:216:
    std::basic_ostream<_CharT, _Traits>&
    std::operator<<(std::basic_ostream<_CharT, _Traits>&, char) [with _CharT =
    char, _Traits = std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:221:
    std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char,
    _Traits>&, char) [with _Traits = std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:227:
    std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char,
    _Traits>&, signed char) [with _Traits = std::char_traits<char>]
    /usr/local/mn10300-linux/include/g++-v3/bits/std_ostream.h:232:
    std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char,
    _Traits>&, unsigned char) [with _Traits = std::char_traits<char>]
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Hayashi,

    It's very likely that you're building in 32-bit mode so Int64 should be 'long long' (see include/IceUtil/Config.h) Why do you expect 'long int'?

    Best regards,
    Bernard
  • syseekersyseeker Member
    Hi Bernard,

    Thanks for pointing out, you're right, I should have looking for long long. Unfortunately the customized g++ ostream lib does not seems to support 64 bit integer, I must change typedef Int64 to only 32 bit, :|, it seems weird to do that, do you think of any good idea?
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Hayashi,

    No, that's not a good idea. Ice / Ice-E needs a 64-bit integer, used in particular to map the Slice 'long' type.

    Are you sure you don't have a 64-bit signed integer on your platform?

    Bernard
  • syseekersyseeker Member
    Hi Bernard,

    I think my choice is only limited to 'candidates' in #4 & #5 :| In this case I think the only match is either 'long int' or 'long unsigned int'. This is referring to ostream (cout <<). The system actually supports long long data type.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    If it's only the C++ stream library operator<< which lacks support for the long long type, you could implement a "string int64ToString(Int64 value)" method and change the code which is using the stream operator<< with Int64 values to first convert the Int64 value to a string with this new method. We already have a stringToInt64 method in include/IceUtil/InputUtil.h and src/IceUtil/InputUtil.cpp, this method could be added in these files.

    Let us know if you need more help with this!

    Cheers,
    Benoit.
  • syseekersyseeker Member
    OK well, I have type cast "case 147: ... sstr << (long int)intVal->v" in Grammar.cpp, and equivalent line in Grammar.y, also the same in Time.cpp IceUtil::Time::toDuration(). I am wondering any bad runtime consequences with this casting.

    Well, compilation is running. Very strange, CplusplusUtil.cpp takes very very long to be successfully compiled. I made it once by leaving the workstation run overnight, this morning when I came it has successfully compiled. Now due to changes in Config.h and etc, it's recomiling...
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    I believe you might get problems if you define a long long constant value in a Slice file, for example:

    const long r1 = 9223372036854775807;

    The Time::toDuration() method might report bogus values as well -- however, this shouldn't be an issue for the slice2cppe translator since it's not using this method :).

    I suspect you're compiling the translator with optimization turned on. You might want to turn the optimization off in config/Make.rules (comment out the definition of the OPTIMIZE variable), this should boost the compilation time (the optimizer is very slow on some old GCC version!).

    Cheers,
    Benoit.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Hayashi,

    Let's take a step back: why do you want to build IceE-trans with this special compiler?

    Is your goal to have a complete IceE development environment *on* your board?

    If you just want to cross-compile from another platform (e.g. from a regular Windows or Linux PC) to this board, then any compiler on that build-platform will do for IceE-trans.

    The IceE source itself does not use iostreams, and should be easier to port than IceE-trans.

    Cheers,
    Bernard
  • syseekersyseeker Member
    Hi Benoit, thanks for your reply. Now I have managed to compile Ice-Trans.
    and Bernard, thank for pointing out your opinion. I need to cross-compile binary (not complete dev env) into this specific board, with this specific cross-compiler (which is based from gcc 3.1 :cool:). Now I am into compiling IceE. First challenge shown below, it's assembler problem, I wonder if it's 3.1 version problem again, which mismatch to some code in Communicator.cpp (those cpp before Communicator.cpp have successfully compiled)

    making all in src
    make[1]: Entering directory `/root/usr/IceE-1.1.0/src'
    making all in IceE
    make[2]: Entering directory `/root/usr/IceE-1.1.0/src/IceE'
    mn10300-linux-g++ -c -I.. -I../../include -I/root/usr/include -L/root/usr/lib -DICE_API_EXPORTS -ftemplate-depth-128 -Wall -D_REENTRANT -fPIC -g Communicator.cpp
    /tmp/ccTua5KK.s: Assembler messages:
    /tmp/ccTua5KK.s:3130: Error: Invalid opcode/operands
    /tmp/ccTua5KK.s:3131: Error: Unrecognized opcode: `a2'
    make[2]: *** [Communicator.o] Error 1
    make[2]: Leaving directory `/root/usr/IceE-1.1.0/src/IceE'
    make[1]: *** [all] Error 1
    make[1]: Leaving directory `/root/usr/IceE-1.1.0/src'
    make: *** [all] Error 1
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Hayashi,

    This looks like a bug in your mn10300 toolchain: mn10300-linux-g++ generates assembly code that the assembler does not understand. I'd recommend to contact whoever maintains this toolchain.

    Communicator.cpp is a generated file, so it is possible, although very unlikely, that this is due to a problem with the code generated by your IceE-trans.
    I need to cross-compile binary (not complete dev env) into this specific board

    IceE-trans contains only build tools -- no runtime component -- so my advice is to use a supported compiler to build it on your development platform.

    Cheers,
    Bernard
  • syseekersyseeker Member
    Hi Bernard, Thanks for your prompt reply.
    bernard wrote:
    Communicator.cpp is a generated file
    May you explain more about this? I thought Communicator.cpp is not generated in compilation time, since it comes together in the source distribution?
    bernard wrote:
    so it is possible, although very unlikely, that this is due to a problem with the code generated by your IceE-trans.
    At this stage of compilation, I haven't seen any usage of IceE-trans for communicator.cpp compilation in IceE...
    bernard wrote:
    IceE-trans contains only build tools -- no runtime component -- so my advice is to use a supported compiler to build it on your development platform.
    Well i rebuilt IceE-trans with my RH9 env which has gcc3.2, make install into a $prefix path, then cross-compile IceE which using the same $prefix path, still the same error. I am looking for tentative solution to overcome this error. Unfortunately support to this toolchain is very minimum.

    Cheers,
    Bernard
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    Yes, the Communicator.cpp file is actually not generated in Ice-E -- I think Bernard got confused because it's generated in Ice.

    I'm afraid, this error really looks like a bug in your compiler, the assembly code generated by the compiler can't be translated by the assembler :(. As Bernard recommended, the best would be to contact whoever maintains the toolchain for your compiler.

    Did you try to compile the other source files? Do they all compile fine or is there similar errors? You could also try to check the assembly code and try to figure out which C++ code is actually causing this bogus assembly code. If that's an isolated issue, it could perhaps be worked around in the C++ code (but I'm afraid I doubt this is an isolated issue as Communicator.cpp is quite simple).

    Cheers,
    Benoit.
  • syseekersyseeker Member
    Hi Benoit,

    It turns out
    Communicator.cpp
    FactoryTableDef.cpp
    Instance.cpp
    LocalException.cpp
    Network.cpp
    Proxy.cpp and
    Reference.cpp

    produces 1 Unrecognized opcode: `a2' error each, and LocalException.cpp produces 5 Unrecognized opcode: `a2'. Are they sharing any significant similarities?

    I commented these file from Makefile, the compilation ended with a segmentation fault following a core dumped...(which is reasonable i guess)

    making all in src
    make[1]: Entering directory `/root/usr/IceE-1.1.0/src'
    making all in IceE
    make[2]: Entering directory `/root/usr/IceE-1.1.0/src/IceE'
    rm -f ../../lib/libIceE.so.1.1.0
    mn10300-linux-g++ -shared -Wl,--enable-new-dtags -Wl,-rpath,/root/usr/IceE-1_1_0/lib -ftemplate-depth-128 -Wall -D_REENTRANT -fPIC -g -L../../lib -o ../../lib/libIceE.so.1.1.0 -Wl,-h,libIceE.so.11 BasicStream.o Buffer.o BuiltinSequences.o Cond.o Connection.o Current.o DefaultsAndOverrides.o Endpoint.o ExceptionBase.o FacetMap.o FactoryTable.o Identity.o IdentityUtil.o Incoming.o IncomingConnectionFactory.o Initialize.o LocalObject.o Locator.o LocatorF.o LocatorInfo.o
    Logger.o LoggerF.o LoggerI.o LoggerUtil.o Object.o ObjectAdapter.o ObjectAdapterFactory.o OperationMode.o Outgoing.o OutgoingConnectionFactory.o Properties.o ProxyFactory.o RecMutex.o ReferenceFactory.o Router.o RouterF.o RouterInfo.o RoutingTable.o
    RWRecMutex.o SafeStdio.o ServantManager.o Shared.o StaticMutex.o StringUtil.o Thread.o ThreadException.o Time.o TraceLevels.o TraceUtil.o UnknownEndpoint.o UUID.o Acceptor.o Connector.o EndpointFactory.o TcpEndpoint.o Transceiver.o -ldl -lpthread
    collect2: ld terminated with signal 11 [Segmentation fault], core dumped
    make[2]: *** [../../lib/libIceE.so.1.1.0] Error 1
    make[2]: Leaving directory `/root/usr/IceE-1.1.0/src/IceE'
    make[1]: *** [all] Error 1
    make[1]: Leaving directory `/root/usr/IceE-1.1.0/src'
    make: *** [all] Error 1

    I am contacting the toolchain developer. A workaround by looking into C++ code might help better...
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    Without seeing the assembly code, I'm afraid it's impossible to say what could cause the error. I recommend you to take a look at it and see if you can find the corresponding C++ code. The segmentation fault of the linker doesn't sound good either, even if some objects are missing, it shouldn't segfault -- it should eventually report undefined symbol errors.

    Is your tool chain properly working to compile other C++ programs? Is there perhaps a more recent version of the tool chain that could try?

    Btw, if you have a commercial interest in this compiler/platform, we could provide you consuling services to help you figuring out the feasability. If you're interested, please contact us at [email protected].

    Cheers,
    Benoit.
  • syseekersyseeker Member
    Hi Benoit,

    Interesting. Looks like the errors are happened under same command in the 6 cpp files ( Network.cpp does not cause this error), which is

    add _GLOBAL_OFFSET_TABLE_-(.LIL31-(.)),a2 (Italic is variable)

    a search for "GLOBAL_OFFSET_TABLE" returns multiple results in the .s files. But only 1 error is prompted in each (except LocalException.cpp returns 5).

    Well, this is a very early stage of laboratory research into ORB-based solution :) , we are interested into IceE because the performance is reported to be very good on embedded system, and I am doing a porting and following that a series of performance benchmark of different ORB solution on this board. I am very appreciate for your excellent supports, and I understand maybe you can't help much from here onwards since it's specific toolchain problem. Thank you!
  • syseekersyseeker Member
    Hi all,

    I traced back and suspected that it is caused by compiling these codes into dynamic shared libraries. I turned on OPTIMIZE_SIZE (-O3). GLOBAL OFFSET TABLE is used by PIC to refer address of global variables, and different optimization mode may produce different PIC (I guess), so the consequence of getting Unrecognized opcode/operand in different files is, maybe, possible.

    Since it's dynamic library problem, I changed to STATICLIB=YES options, now the problem has solved. But the solution of why this assembler error happens with -fPIC macro given during compilation is still unknown.
  • syseekersyseeker Member
    Hi all,

    I traced back and suspected that it is caused by compiling these codes into dynamic shared libraries. I turned on OPTIMIZE_SIZE (-O3). GLOBAL OFFSET TABLE is used by Position Independent Code(PIC) to refer address of global variables, and different optimization mode may produce different PIC (I guess), so the consequence of getting Unrecognized opcode/operand in different files is, maybe, possible.

    Since it's dynamic library problem, I changed to STATICLIB=YES options, now the problem has solved. But the solution of why this assembler error happens with -fPIC macro given during compilation is still unknown.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    Thanks for the update, I'm glad it works when you use static libraries! Did you try running the test suite (with the ./allTests.py script at the top of your Ice-E distribution)?

    As for the issue with the assembler error when using -fPIC, you should perhaps consider updating your toolchain to use a recent GCC version? For instance, it looks like several bugs have been fixed for -fPIC and mn10300, see here and here.

    Cheers,
    Benoit.
Sign In or Register to comment.