Link error compiling with Mac OSX and Xcode

  • Limdor

    Limdor - 2012-07-15


    I'm trying to compile Assimp for Mac OSX but I allways get the same error. I do with the Xcode project but if I try to do with Makefile I get the same error. Any idea?
    Congratulations for the great job, assimp is an amazing useful library!


    Ld workspaces/xcode4/code/Release/libassimp.dylib normal x86_64
        cd /Users/Limdor/Desktop/assimp-3.0.1270-sdk
        setenv MACOSX_DEPLOYMENT_TARGET 10.7
        /Applications/ -arch x86_64 -dynamiclib -isysroot /Applications/ -L/Users/Limdor/Desktop/assimp-3.0.1270-sdk/workspaces/xcode4/code/Release -F/Users/Limdor/Desktop/assimp-3.0.1270-sdk/workspaces/xcode4/code/Release -filelist /Users/Limdor/Desktop/assimp-3.0.1270-sdk/workspaces/xcode4/code/ -install_name /Users/Limdor/Desktop/assimp-3.0.1270-sdk/workspaces/xcode4/code/Release/libassimp.dylib -mmacosx-version-min=10.7 -dynamiclib -Wl,-headerpad_max_install_names /usr/lib/libz.dylib -single_module -compatibility_version 3.0.0 -current_version 3.0.1264 -o /Users/Limdor/Desktop/assimp-3.0.1270-sdk/workspaces/xcode4/code/Release/libassimp.dylib

    ld: malformed 64-bit a.b.c.d.e version number: 3.0.1264
    clang: error: linker command failed with exit code 1 (use -v to see invocation)

  • Kim Kulling

    Kim Kulling - 2012-07-16


    do you have tested the makefiles generated by the CMake-build system? Or are you using the manual generated makefiles?


  • Limdor

    Limdor - 2012-07-16

    I've tried with the makefiles generated by CMake and with the XCode projecte also generated with CMake. Both with the same result.

  • Tiger

    Tiger - 2012-07-17

    Hi, I'm having the same issue when trying to build assimp with the cmake generated Makefiles on osx.

    I just tried what google says on this error message and it seems it comes from the linker (ld64) when trying to parse the version number. It seems ld64 tries to pack the version number into a uint64_t and expects the version number in the folowing format: a.b.c.d.e where a has 24 bit and b,c,d,e each 10 bit of size (sums up to 64 bit, for implementation see and search for "Options::parseVersionNumber64"). Appearently 3.0.1264 fails this check.

    According to this information I tried the folowing:

    I changed  ASSIMP_SV_REVISION to 1023 in CMakeLists.txt and it worked. But that's not the kind of fix I would prefer ^_^

    Hope this helps you.

    Best regards

    Assimp is really impressing. Keep up the good work!

  • Alexander Gessler

    Ok, this is embarassing if true.

    Seems we have no choice than to drop the major.minor.svnRevision scheme for OSX.

    If anybody is ok with it, let's just drop the third number (it is, in a certain sense, redundant, but I always find it useful to know from which SCM revision a release originated).

    Bye, Alex

  • Alexander Gessler


  • Limdor

    Limdor - 2012-07-18

    If I understand properly the problem is that the 2nd, 3th and 4th number cannot be bigger than 1023. At the moment only 3 numbers for the version are used, maybe an alternative version for OSX if you want to know the svn number could be tu use the last 2 number to represent the svn number revision basis 1024.


    The version 3.0.1264 could be something like

    I know that doesn't look nice but it's a way to mantain all the information. If the developers prefer othe solution I will accept them. I just want to compile :-)

  • Limdor

    Limdor - 2012-07-18

    I know that will be the same problem when the svnRevision reach to 1048576 but if the last 400 revision have been done in the last two years and the progression is the same, then the svnRevision number will reach to 1048576 in about 5.000 years. If Assimp still alive could be great to have the sampe problem again.

  • Limdor

    Limdor - 2012-07-18

    Sorry for posting again, I've checked the link of sourcetiger and it seems that the 32 bits version have a maximum of 255.
    If we don't want to have problems with 32 bits maybe we could do basis 256 and we will have the problem in about 300 years instead of 5.000.


  • Tiger

    Tiger - 2012-07-18

    Unfortunately it won't work for the 32-bit numbers, since they are expected as a.b.c so we have only 0-255 for the revision part.

  • Limdor

    Limdor - 2012-07-18

    Sorry, I thought that 32 bits had 4 numbers too. Now that I think, there is any OSX 32 bits or now all are 64?

  • Tiger

    Tiger - 2012-07-18

    The most should be on 64-bit, but nevertheless you have the option to also run/build 32-bit.

  • Alexander Gessler

    300 years is not enough, this is for eternity.

  • vade

    vade - 2012-07-22

    If you need to build today, you can clear your CMake caches, and edit the CMakeLists.txt and change

    set (ASSIMP_SV_REVISION 1264)

    to whatever you want below 256, which seems to have worked for me. I build using UNIX Make files, because I was having issues with  Boost (1.50) headers not compiling in Xcode.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks