Archived

This forum has been archived. Please start a new discussion on GitHub.

Ice Compilation

Hi,

I trying to compile ICE with a cross compiler. And the target system don't support the type wchar_t, consequently the compiler (g++) haven't wstring (Unicode).

What can I do? Thanks.

Ps : sorry for my english :)

Comments

  • Hmmm... I haven't looked at this in any detail, but it should be possible to do without wchar_t/wstring. You'd have to modify the places in the code where we use these types (not all that many, I believe) and basically stub out the wide char functionality. I suspect that's not a trivial exercise though.

    There may not be any cheap fix with a compiler that does not have wchar_t as a native type. You might just get away with redefining wchar_t as unsigned int or some such. (But again, I haven't tried this.)

    Cheers,

    Michi.
  • dwayne
    dwayne St. John's, Newfoundland
    Hi,

    Have you tried using Ice-E instead of Ice? With Ice-E it is possible to easily disable the wstring support. Unless there are some features of Ice that are not included in Ice-E that you require, I would suggest you take a look at Ice-E.

    Dwayne
  • Thanks, but I'm interesting by IceStorm on Ice...

    I trying to generate a compiler with wchar_t support, but it's difficult because the configuration test don't run.

    May be i can just add the library who implement the wchar.h functions in compilation rules of GCC?

    Cheers.
  • dwayne
    dwayne St. John's, Newfoundland
    If you don't actually need to run the IceStorm server itself on the platform you are trying to cross-compile for you can still use Ice-E. Ice-E publishers/subscribers works fine with IceStorm. You just need run slice2cppe on IceStorm.ice slice file yourself, and then include the generated file in your Ice-E application.

    Dwayne
  • IceE need pre installation of slice2cppe?

    Because i have the same problem. IceE-trans don't run because of Unicode.h
  • dwayne
    dwayne St. John's, Newfoundland
    Hi,

    What os/compiler are you using to build slice2cppe? This would be the system you are developing on, not the target system you are cross-compiling for? You should not need to build slice2cppe for the target system itself.

    Dwayne
  • It's running with the gcc of host. My OS is a RedHat.
    Where i can find informations on how running both IceE and IceE-trans?

    Thanks very much for your help.
  • dwayne
    dwayne St. John's, Newfoundland
    Hi,

    There are INSTALL/README files included in the Ice-E and Ice-E translators source distributions that talk about how to use them. Basically what you need to do is:

    1. Download the Ice-E translator source distribution and build the translators using your development platforms regular compiler, not the cross compiler, and then add the location of the slice2cppe executable to your PATH.

    2. Download the Ice-E source distribution and build that using your cross compiler.

    On the Ice-E download page there are also precompiled translator binaries for RedHat 4 that you may be able to use rather than compiling the translator yourself.

    Dwayne
  • Hi,

    I try to compile IceE, and I think I have a biggest problem than wstring...
    I haven't shutdown, getsockname, getpeername, getaddrinfo and freeaddrinfo on my target system...

    And I think it's difficult to add this.
    Exemple of definition on newlib-1.16.0:
    _sockcall2(int,shutdown,int,fd,int,how) in socket.c

    I search shutdown.c, getsockname.c,.. on net for creating a library but I don't find a "standard" implementation of this functions.

    Cheers,
    kraps33.
  • benoit
    benoit Rennes, France
    Hi,

    I'm afraid compiling Ice/E without these methods is going to be difficult. You'll need to figure out alternatives for each of the missing methods if some are available on your target platform (e.g.: getaddrinfo could be replaced with gethostbyname if it's available, etc). If not available, you'll need to figure out how to modify Ice-E to not rely on them (e.g.: getpeername is not essential since it's mostly used for tracing).

    Cheers,
    Benoit.
  • Hi,

    Thanks for gethosbyname, its available.
    For shutdown, getsockname and shutdown I think i have found solutions.
    Lacking freeaddrinfo...

    Without this. IceE seems to be almost comiled, only the linking part is remaining (crt0.o problem :) ).

    Cheers.
  • benoit
    benoit Rennes, France
    You don't need freeaddrinfo if you replace getaddrinfo with gethostbyname.

    Cheers,
    Benoit.
  • Hi,

    I have created a patch for IceE -> a repository iceE-patch/ with src/ include/ lib/

    I have added pthread_mutexattr_settype and gettimeofday ".c" and ".h" and others non-defined macros on my target system.

    All the .o files are created but my libIceE.a don't countain this functions...
    Whereas I have added -I/header_path and -L/lib_path on compilation rules.

    nm libIceE.a
    > U pthread_mutexattr...
    > U gettimeofday
  • Hi,

    It's good for my patched functions. I have forbidden #ifdef __cpluplus extern "C" {... in my header files :).

    Now I have a new problem.
    "multiple definition" when I compile libIceE.so.
    The target function is upCast.
    It is possible that my compiler don't support override??? It's strange.

    Cheers,
    kraps33.
  • Linkage problem

    Hi,

    I have a big problem with IceE since last week.
    IceE run in native compil but not in cross compil...

    The problem seems provide of upCast function...
    LocalException.o(.sbss+0x0):IceE-1.2.0/src/IceE/LocalException.cpp:676: multiple definition of `in'
    DefaultsAndOverrides.o(.sbss+0x0):IceE-1.2.0/src/IceE/DefaultsAndOverrides.cpp:18: first defined here
    Network.o(.sbss+0x0):/inst_gcc-3.4.6///include/c++/3.4.6/bits/stl_vector.h:256: multiple definition of `in'
    DefaultsAndOverrides.o(.sbss+0x0): first defined here
    Acceptor.o(.sbss+0x0):../../src/TcpTransport/Acceptor.cpp:22: multiple definition of `in'
    DefaultsAndOverrides.o(.sbss+0x0): first defined here
    Connector.o(.sbss+0x0):../../src/TcpTransport/Connector.cpp:22: multiple definition of `in'
    DefaultsAndOverrides.o(.sbss+0x0): first defined here
    TcpEndpoint.o(.sbss+0x0):../../include/IceE/BasicStream.h:604: multiple definition of `in'
    DefaultsAndOverrides.o(.sbss+0x0): first defined here
    Transceiver.o(.sbss+0x0):../../src/TcpTransport/Transceiver.cpp:23: multiple definition of `in'
    DefaultsAndOverrides.o(.sbss+0x0): first defined here
    make[2]: *** [../../lib/libIceE.so.1.2.0] Error 1

    Thanks for your help.
  • matthew
    matthew NL, Canada
    Please don't post a duplicate thread on an existing issue. If you want our attention then please add information to the existing thread.
  • bernard
    bernard Jupiter, FL
    Hi Sebastian,

    I don't see any variable named 'in' in this Ice-E source code.

    If you modified the Ice-E code to support your own system, it's going to be difficult to help you! Did you change headers/includes/variable names as part of your port?

    Could you also specify the exact platform you're porting to, including compiler version?

    Cheers,
    Bernard
  • Hi,

    I have just add 3 headers to define errno.h variables or functions like gettimeofday, pthread_mutexattr_settype...
    And a library to implement this.

    I just add in 5 files macros likes #ifdef _MYOS #include <...> #endif (Config.h, Time.cpp, Network.h, Instance.cpp, Network.cpp)

    My headers are protected (#ifndef __MYTYPES_H #define ...) and they countain only functions declarations, structures or #define VARIABLES.

    I have found this in Acceptor.s and DefaultsAndOverrides.s (for "in"):
    .file "Acceptor.cpp"
    .globl in
    .section ".sbss","aw",@nobits
    .align 2
    in:
    .zero 4
    .size in, 4
    .type in, @object
    .section ".text"
    .align 2
    .globl _ZN11IceInternal6upCastEPNS_8AcceptorE
    .type _ZN11IceInternal6upCastEPNS_8AcceptorE, @function
    _ZN11IceInternal6upCastEPNS_8AcceptorE:


    .file "DefaultsAndOverrides.cpp"
    .globl in
    .section ".sbss","aw",@nobits
    .align 2
    in:
    .zero 4
    .size in, 4
    .type in, @object
    .section ".text"
    .align 2
    .globl _ZN11IceInternal6upCastEPNS_20DefaultsAndOverridesE
    .type _ZN11IceInternal6upCastEPNS_20DefaultsAndOverridesE, @function
    _ZN11IceInternal6upCastEPNS_20DefaultsAndOverridesE:

    For system. I work under POSIX operating system (it is the target system, with newlib 1.8) on PowerPC processor.

    Cheers,
    Sebastien.
  • bernard
    bernard Jupiter, FL
    It looks like one of your headers define this 'in' global variable; or perhaps it's a macro that somehow defines 'in' in the upCast function definition.

    You could pre-process one of these files (gcc -E) and try to locate this 'in' definition in the output.

    Cheers,
    Bernard
  • struct in_addr in;

    In a header file of target system...

    It run better with an "extern" :).

    Thanks for your help.