Porting on Linux

by - 15:24

Another brief post, now about my experience to port on Linux. This may sound something trivial to Linux experts but perhaps will save a few hours of tedious work to someone who is not a guru.

I was following the Build Instructions outlined in the OCC user’s documentation to use autoconf/automake tools. My build box was RHEL4 Update 4. So I diligently downloaded the OCC source archive, ungzipped’ed it and ran ./configure with some required options (e.g. --disable-wrappers,...). Then make.

There were multiple hiccups along the way but after several hours I could get built libraries inside ./ros/adm/make/*/.libs. To my surprise they did not contain the .so suffix and so I was stuck as I could not do anything about it. I emailed to my colleagues at OCC begging for some help. They were generous enough to offer some hints, so thanks for that again Igor ;-) ! In parallel, Google gave a couple of helpful links as well:
http://lists.kde.org/?l=kdevelop&m=111840274221191&w=2
http://osdir.com/ml/gnu.libtool.bugs/2003-07/msg00005.html

Root-cause: it was a mismatch between the libtool pre-installed on the system (which was of version 1.5.6) and ltmain.sh shipped with OCC (which expected libtool 1.4.3). Linking ./ros/make/ltmain.sh to /usr/share/libtool/ltmain.sh solved the problem. ./configure and make went smoothly and now all the libraries do contain .so.

This experience made me think that this step – ignoring shipped ltmain.sh and using pre-installed one should just always be done.

Any thoughts on this ?

P.S. Looking deeply into libtool which is autodenerated by ./configure, I still can’t figure out when ${shared_ext} is being defined to .so. So if anyone has mastered all this mechanism, I’d be interested to know ...

You May Also Like

8 comments

  1. I don't know a libtool as you pointed out, but I did succeed to use the direct OpenCascade libraries that are provided with Ubuntu ( http://narocad.blogspot.com/2009/02/possible-future-fundation-for-naro.html ) and they are right now up-to-date. This blog post is fairly old (one year in the past) but I think that Ubuntu at least will not remove right away.
    Also compiling on Ubuntu will make that final binary will be compatible with other distros (if is compiled against the same LibC in general) and you will not spend that much time on fixing linking issues.
    Hope it helps!

    ReplyDelete
  2. Thanks for this reference ciplogic.
    I'm currently struggling with rebuilding OCC in debug mode - as I have discovered a Segmentation Fault with MMGT_REENTRANT=1 and cannot debug with release version which was compiled without the '-g' option.
    Unlike Windows, it's impossible to have debug and release binaries compiled side-by-side, so extra efforts are required to have both.

    ReplyDelete
  3. I started to explore Open Cascade two years ego on Red Hat Linux and it was hard work to compile it. Now I switched to Debian Lenny and the compilation (debug and release) was absolutely no problem. I use Eclipse as my IDE and it supports to debug the library.
    Regards Chris

    ReplyDelete
  4. Hi Roman,
    I am not sure if you still work with Open Cascade and Linux, but possibly you have some ideas. I compiled the Qt Import-Export Example for 64bit Linux, but unfortunately I realised that the IGES Import became very unstable. The import of almost all IGES files crashes the application or the geometry will be damaged. I used the _OCC64 Option for the compilation. I realized that the problem is caused by a conflict between Qt and Open Cascade on 64 bit Linux systems. If I remouve all Qt objects and declarations in the program and if I compile and run it as a simple console application everything works fine. Do you possibly have some ideas how to resolve this problem?
    Thank you in advance
    Chris

    ReplyDelete
  5. Hi Chris,
    I am only considering to move to 64bit and currently do not have practical experience at hand. I'll keep your notes in mind when doing my experiments though I don't have Qt GUI running on Linux (only QtCore etc).
    If anything appears, I'll likely make some post about that.
    Roman

    ReplyDelete
  6. Hi Roman,
    QtCore doesn't cause the problem. As soon as I declare
    int main(int argc, char *argv[])
    {
    QApplication a(argc, argv);
    ......
    }
    the IGES Import starts to fail frequently.
    I already checked the resulting binary file for conflicting symbols and I tried to change the order of the libraries during the linking, additionoly I tried to encapsulate the IGES reader in a different class but I did not yet succeeded to resolve the problem.
    I now found a small test example which consits of the geometry of a simple ball. If I import it without the declaration of QApplication inside the main procedure everything is O.K. With QApplication the geomerty is damaged and the debug output is:
    *****************************************
    Total number of loaded entities : 14.
    Warning: IGESToBRep_IGESBoundary: Deviation = 149.912
    Warning: IGESToBRep_IGESBoundary: 3D and 2D curves are inconsistent; 3D is ignored
    Warning: IGESToBRep_IGESBoundary: 2D curve of edge was reversed
    Warning: IGESToBRep_IGESBoundary: Deviation = 170.609
    Warning: IGESToBRep_IGESBoundary: 3D and 2D curves are inconsistent; 3D is ignored
    Warning: IGESToBRep_IGESBoundary: Curves 1 and 2 cannot be connected
    Info: ShapeProcess_Context: Reload Resource_Manager: -> IGES
    Warning: XSAlgo_AlgoContainer::ProcessShape(): Sequence FromIGES.exec.op is not defined in read.iges.resource.name resource; do default processing
    Warning: ShapeFix_Wire::FixShifted set vclosed True for Surface of Revolution
    !!!Erfolg
    ****************************************
    Do you think that the problem could be caused by localisation? I use debian Lenny for the german language. Do you possibly have some suggestions?
    If I have more time I will try to debug the problem.

    Thank you in advance
    Chris

    ReplyDelete
  7. Hi Chris,
    No clues upfront. However it sounds like data/memory corruption.
    If I have any thing when moving to 64 bit, I'll share.
    Roman

    ReplyDelete
  8. Hi Roman,
    thank you for your reply! I now managed to resolve the problem. It seems that OpenCascade is using the QT localisation and this causes problems for the IGES ASCII reader. If I set the environment variable LANG=en everything works perfect!! Maybe you may also discover this problem if somebody is using your CAD Exchanger on a german operating system. :-)
    Chris

    ReplyDelete