Link problem on Fedora 13 x86_64

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 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 points to Output of the file utility is: /usr/lib64/ 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

timoor's picture

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, I ran ldd on It reports dependencies on several X libraries, but notably not - 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/ 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 since autoconf fails to run. I'm now thinking it may be a parsing error of output from the file utility as is listed by ldd against 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.

timoor's picture

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.

Björn Hein's picture

Many Thanks! I stumbled upon the same problem on fedora 14 and could not find the solution. With your patch it seems to work...

timoor's picture

You're very welcome.

Roman Lygin's picture

Hi Tim,
Could you post your recommendation on, 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.

P.S. The site has been initiated by Fabian Hachenberg and is gradually growing. If you would like to contribute, please do.

timoor's picture

Will do. Just created my account on the site.