Thu, 02/03/2011 - 10:08
After building 6.3.0 I am able to run DRAWEXE, at least rudimentarily, but encounter a problem running pythonocc which reports (on the helloworld sample) an undefined symbol in TKService.so: XmuCreateColormap. I confirmed this with the nm utility. Perhaps related, looking through the output of make, I notice that file_magic is not working properly for shared system libraries. These libraries generally have base names that are symlinks. In particular libXmu.so points to libXmu.so.6.2.0. Output of the file utility is: /usr/lib64/libXmu.so.6.2.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped. Has anyone encountered a similar problem? The file_magic problem is likely a red herring. I'm thinking maybe the missing symbol(s) have been moved into a different library like Xaw. Autoconf won't produce configure, but its output does complain about file_magic. This is my configure command: ./configure --prefix=/opt/OpenCascade6.3.0 --with-java-include=/opt/jdk1.6.0_21/include --with-tcl=/usr/lib64 --with-tk=/usr/lib64 | & tee configure.out
Thu, 02/03/2011 - 23:50
Incremental progress. I wrote a small C program to make sure my gcc build environment is quite sane. The symbol XmuCreateColormap is where it should be, libXmu.so. I ran ldd on libTKService.so. It reports dependencies on several X libraries, but notably not libXmu.so - though the symbol XmuCreateColormap is listed as undefined by nm. I've encountered problems in the past using LD_LIBRARY_PATH, so I created an entry under /etc/ld.so.conf.d for OCC and ran ldconfig to avoid having to use it. My tentative conclusion is that the problem is rooted in the file_magic weirdness after all. All the libraries listed in the gcc link path should show up with ldd. Here is partial output from make in TKService dir:
*** Warning: linker path does not have real file for library -lXmu.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libXmu but no candidates were found. (...for file magic test)
I will fix this problem! It's almost certain to reside in configure.in since autoconf fails to run. I'm now thinking it may be a parsing error of output from the file utility as libXau.so is listed by ldd against libTKService.so and that library is also in (and only in) /usr/lib64. I will post my findings if I'm successful as it may help some other Fedora 13 users.
Sun, 02/13/2011 - 00:04
The solution to this problem turns out to be quite easy. At ~ line 5329 in the configure script there is a switch statement. Add a 'linux' entry that duplicates the one for 'beos' and specifies 'pass_all'. This will disable the file_magic facility and shared library linkage will be done properly. I still have problems with some of the pythonocc examples, segv's, but OCC linkage does not appear to be implicated. Hope this is helpful to someone.
Mon, 02/14/2011 - 01:45
Many Thanks! I stumbled upon the same problem on fedora 14 and could not find the solution. With your patch it seems to work...
Fri, 02/18/2011 - 03:10
You're very welcome.
Thu, 02/17/2011 - 11:11
Hi Tim,
Could you post your recommendation on http://opencascade.wikidot.com/buildocc, creating a new section for that?
Similar request to everybody - if you discover new experience on how to solve the build (or other) problem, please feel to concisely document it and post. This will help other developers and hopefully OCC team when providing support for new platforms.
Thanks,
Roman
P.S. The http://opencascade.wikidot.com site has been initiated by Fabian Hachenberg and is gradually growing. If you would like to contribute, please do.
Fri, 02/18/2011 - 03:12
Will do. Just created my account on the site.