Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    64bit osx (part II) linking

    General and Desktop
    3
    6
    3845
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mirswith last edited by

      I am trying to link the libx264 library to one of my apps but I am getting linking errors saying it can not find various symbols for the x86_64 architecture:

      Undefined symbols for architecture x86_64:
      "x264_param_default_preset(x264_param_t*, char const*, char const*)", referenced from:

      I have verified that I compiled the libx264 library using x86_64:

      lipo -info libx264.a
      input file libx264.a is not a fat file
      Non-fat file: libx264.a is architecture: x86_64

      I also checked to see if the missing symbols exist in the library:

      nm libx264.a | grep x264_param_default_preset
      0000000000001710 T _x264_param_default_preset
      0000000000005e88 S _x264_param_default_preset.eh

      I am trying to link as a static library.

      Are there some additional parameters I need to set when compiling libraries to get them to be compatible with Qt or can someone point me in the right direction?

      Thanks again.

      -=ben

      1 Reply Last reply Reply Quote 0
      • L
        loladiro last edited by

        Could you post the part of your .pro file, where you are linking your libs?
        Also, there was a similar thread before (maybe you have the same problem):
        http://developer.qt.nokia.com/forums/viewthread/5665

        1 Reply Last reply Reply Quote 0
        • M
          mirswith last edited by

          Sure thing:

          @
          TARGET = myLib
          TEMPLATE = lib

          ... headers/source removed for readability ...

          macx {

          LIBS += /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit
          /Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL
          ../../../common/x264/libx264.a
          ../../../common/ffmpeg/libswscale/libswscale.a

              QMAKE_LFLAGS_SONAME = -Wl,-install_name,@executable_path/../Frameworks/
          

          }@

          Thanks for the other posting link, unfortunately it has not helped me.

          Thanks.

          -=ben

          1 Reply Last reply Reply Quote 0
          • G
            goetz last edited by

            I can reproduce the problem. It's nothing Qt specific, though.

            The x264 library does not support C++ out of the box. It is a pure C library, so it uses the C style "name mangling":http://en.wikipedia.org/wiki/Name_mangling, if you just include the headers in a C++ source, the compiler wants to apply C++ style name mangling - so it tries to link different names which are not available in the lib.

            So, the solution simple: Wrap the #include with extern "C" this way:

            @
            #include <stdint.h>

            // enforce C style name mangling
            extern "C" {
            #include "x264.h"
            }
            @

            This switches on C name mangling for the functions in this header file.

            http://www.catb.org/~esr/faqs/smart-questions.html

            1 Reply Last reply Reply Quote 0
            • M
              mirswith last edited by

              That was it! You made my day and I learned something to boot. :)

              Are there any ways to tell what type of name mangling is being used to help troubleshoot this in the future?

              Thanks again!

              -=ben

              1 Reply Last reply Reply Quote 0
              • G
                goetz last edited by

                If you do not setup anything, then the default name mangling is used. If you have a C library that is usesful from C++ as well, it is good practice to put that extern stuff into the header of your libraray. The usual pattern is:

                @
                #ifdef __cplusplus
                extern "C" {
                #endif

                // your actual header files goes here

                #ifdef __cplusplus
                }
                #endif
                @

                See the "C++ FAQ on 'How to mix C and C++'":http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html for some more details.

                Unfortunately there is no easy way to tell if the header has the "extern" other than actually looking into it.

                http://www.catb.org/~esr/faqs/smart-questions.html

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post