Menu

Building on Darwin

2001-11-23
2001-11-28
  • Scott Newbern

    Scott Newbern - 2001-11-23

    I am attempting to configure / make on OSX / Darwin.

    A bit of pre-configure work needs to be done to install necessary utilities not included with the Mac Developer tools.  (e.g. tk, X11, g77, etc.)
    I had most of this as a result of porting other code.  All are available from fink: fink.sourceforge.net

    Since Darwin is new, it also takes some work to make configure run as desired.
    1a) Some includes and libs are not in the place configure expects them.  Place holders or links need to be made to fix these.  (In one case it was not clear a link needed to be made until during the compile process.)
    1b) As expected configure needs to be told where some of those includes and libs are located.  And in at least one case configure does not have a specific flag to prescribe a path to look at.

    2) configure adds extra newline characters in the sed command sections.  (I've run across others having this problem with other configure scripts on Darwin.)  I got around this problem by editing config.status and just executing it.

    Once trying to compile, I learned that System V Semaphores were not included in the Darwin distribution, yet the source code was.  I found that John Bellardo made a Kernel extension for SysVsem.  These are available at: www-cse.ucsd.edu/~bellardo/xnu/sysvsem.html, Thanks!
    He modified the sem.h header and you have to "unmodify" it for proper compilation.

    (BTW: The omision of SysVsem was posted as a bug on the Apple developer site.)

    After all this, things appear to go OK.  Most of the libraries compile.

    Now I'm having a link error.
    In building TTOPOLOGY, an undefined symbol error occurs during link.  I've checked the link files and the symbol is included and properly named.

    I tried running ranlib on the appropriate libraries and it didn't help.

    The response is as if the libraries are out of order in the command line.  Yet it looks as though they are in the proper order.  There are a lot of libraries in this particular command sequence, so I'm not completely sure I haven't examined the order in enough detail to be sure.

    I'm going to continue to try to figure this out.  Any help will be greatly appreciated.  Also I sent rboehne (to the email link on the AutoConfig web site) notes on the first few errors so if you are now reading this here, it's not deja vu , I'm the same person.

    Thanks,
    -Scott

     
    • Robert Boehne

      Robert Boehne - 2001-11-26

      Scott,

      This is exactly where I had the trouble with FreeBSD.  I would suggest you create a very simple program that calls some stuff in TKernel, and prints to std output.  If this fails it will be much easier to track it down.

      Secondly, you appear to be building static libs, why?  If you link to static libs you sometimes need to include the same lib more than once in your link line.  Shared libs can depend on each other and only have to be listed once.  With static libs, if two libs depend on each other (as I think some CASCADE libs do) you need to list them like this:  -lfoo -lbar -lfoo.  Libtool normally handles this but with the massive scale that these libraries are on, this can't be done.  The list of libraries will be so long that they are too large for a single command line on many systems.  Even if they could be executed, computing them would cause open cascade to take weeks to compile.

      Let me know how it goes.

      Robert

       
      • Scott Newbern

        Scott Newbern - 2001-11-28

        OK, I'll try that, but I've started over with the latest files from the Matra CVS as you have suggested.   So, I'm not to that point yet.  Maybe the problem is related to your second coment.  Libtool is handling the long link list, But maybe it drops part of them because the line is too long, so it never sees the lib that contains the "undefined symbol."

        And the shared lib problem was something I initially decided to look at later.

        Now that I'm starting over, I'll look at this now.

        Configure finds the darwin dynamic linker, dyld, just fine.  Configure thinks that ld, and libtool do not support shared libraries.  Yet they actually do.

        Here's the config.log snipet:
        configure:5128: checking whether the cc linker (/usr/bin/ld) supports shared libraries
        configure:5866: result: no
        configure:5931: checking how to hardcode library paths into programs
        configure:5955: result: immediate
        configure:5969: checking whether stripping libraries is possible
        configure:5977: result: no
        configure:5981: checking dynamic linker characteristics
        configure:6387: result: darwin5.1 dyld
        configure:6930: checking if libtool supports shared libraries
        configure:6932: result: no
        configure:6935: checking whether to build shared libraries
        configure:6954: result: no
        configure:6957: checking whether to build static libraries
        configure:6961: result: yes

        Another note:  the test for libGL looks only for libGL.so, so I had to add another statment to look for libGL.dylib.  .dylib is the Darwin extension for dynamic libs.

        Thanks,
        -Scott

         
    • Scott Newbern

      Scott Newbern - 2001-11-28

      I think this has to do with the way Mach-0 treats dynamic , static and module libraries.

      See:
      http://fink.sourceforge.net/doc/porting/shared.php
      (Thanks again to all who support Fink)

      Maybe the configure script doesn't account for this.

      -Scott

       
      • Robert Boehne

        Robert Boehne - 2001-11-28

        To reiterate, the configure script will try to call the C or C++ compiler you specify and link the library with -lGL.  If you do not have this library in the compiler's default search path for librarys you have to add it explicitly with --with-gl-library=DIR.  The same is true for Xmu, tcl, tk, X, and the include files they need.  There are command line arguments to configure to handle all of these.
        The CVS version of Libtool should be able to handle Darwin, if not we'll fix it as I'm a Libtool maintainer.  However I don't have access to a Mac OS X machine so you'd have to help me. :)

        Robert                                                                    

         

Log in to post a comment.