Thread: Linker Issue - Getting PortAudio to work with Code::Blocks

  1. #1
    Registered User samGwilliam's Avatar
    Join Date
    Feb 2002
    Location
    Newport
    Posts
    382

    Linker Issue - Getting PortAudio to work with Code::Blocks

    I've installed the SDK and set the right folder for the include path but it's giving me errors, saying undefined references to functions.

    I know what the problem is - something to do with the linker, I'm aware that I've got to tell the linker about the Port Audio linker folder but I don't know what folder to point it at.

    This actually brings up a much deeper problem I've always had - I'm terrible at IDEs/compilers, with the stupendous amount of options they have.

    Not just that, but things like make files and command line switches have always eluded me.

    I first got into programming on the Spectrum, then with my first PC I moved onto GW-BASIC, Q-Basic, then onto Borland Turbo C (and later C++) for DOS.

    So I've always been used to just writing code and (apart from some includes in the case of C/C++) just hitting "Run".

    It's something I've never got around - in the past when faced with compiler/linker errors like this I'd Google the problem and just follow the instructions (never learning from it).

    It's really holding me back and I'd be grateful if someone could help with this Port Audio/Code::Blocks issue, but also maybe point me in the direction of how to get to grips with the "back end" of programming.
    Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)

  2. #2
    Registered User samGwilliam's Avatar
    Join Date
    Feb 2002
    Location
    Newport
    Posts
    382
    It seems that I should be giving Code::Blocks the path of some .lib files - but I searched the Port Audio directory and found no .lib files at all. I know I've managed to get this to work in the past. I'm fairly certain I found the location of the .lib files, so I'm curious as to why they don't exist in this download.

    Can anyone help me there? What I'm trying to do is just write a Windows program that has access to the soundcard. I'd used Port Audio in the past, with success, but maybe it's obsolete now. Can anyone suggest a better alternative? I'm a bit out of the loop these days.
    Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)

  3. #3
    Guest
    Guest
    Do you have access to binaries already? The PortAudio website seems to only offer the source, so you'll likely have to build the libraries first, hence their absence in your downloaded directories.

    This actually brings up a much deeper problem I've always had - I'm terrible at IDEs/compilers, with the stupendous amount of options they have.

    Not just that, but things like make files and command line switches have always eluded me.
    It isn't you, the whole C/C++ ecosystem is notoriously complex and messy in practice. That's why other languages came up with cleaner modular systems.

  4. #4
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    Figure out what compiler you are using? And, add the info to your post or search on the compiler and PortAudio.
    NOTE: Code::Blocks is *not* a compiler.

    Tim S.
    "...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson

  5. #5
    Registered User samGwilliam's Avatar
    Join Date
    Feb 2002
    Location
    Newport
    Posts
    382
    Quote Originally Posted by stahta01 View Post
    Figure out what compiler you are using? And, add the info to your post or search on the compiler and PortAudio.
    NOTE: Code::Blocks is *not* a compiler.

    Tim S.
    The default compiler for C::B, it seems, is the GNU GCC compiler so this will be the one I'm using. Also something called MinGW.
    Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)

  6. #6
    Registered User samGwilliam's Avatar
    Join Date
    Feb 2002
    Location
    Newport
    Posts
    382
    Quote Originally Posted by Guest View Post
    Do you have access to binaries already? The PortAudio website seems to only offer the source, so you'll likely have to build the libraries first, hence their absence in your downloaded directories.
    That would explain the lack of .lib files. I definitely never had this problem when using Port Audio a few years back. I think I was using v17 or v18, though, now I'm using v19 and maybe they expect you to build your own libraries now.

    This is the kind of thing I've always been crap at. Would the extension definitely be .lib? I found some files with extension .la
    Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)

  7. #7
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    Mingw GCC can link to DLLs and since PortAudio is a C library it will likely work correctly.
    So, I suggest looking for DLLs or Mingw GCC import library that uses the ".a" extension.
    Note: Static libs also use the ".a" extension.
    Edit: Linking to an static library would likely work; but, DLLs are normally preferred on Windows.

    Tim S.
    Last edited by stahta01; 06-15-2019 at 09:59 PM.
    "...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson

  8. #8
    Registered User samGwilliam's Avatar
    Join Date
    Feb 2002
    Location
    Newport
    Posts
    382
    Quote Originally Posted by stahta01 View Post
    Mingw GCC can link to DLLs and since PortAudio is a C library it will likely work correctly.
    So, I suggest looking for DLLs or Mingw GCC import library that uses the ".a" extension.
    Note: Static libs also use the ".a" extension.
    Edit: Linking to an static library would likely work; but, DLLs are normally preferred on Windows.

    Tim S.
    Do you mean statically link to a DLL (as in go to the compiler options and set the path containing the DLL, as opposed to the compiled app looking for the DLL at runtime)? The problem I'm having is that the project won't build, so that's the only choice I have (assuming that that's even a thing). I'll give it a try...
    Current Setup: Win 10 with Code::Blocks 17.12 (GNU GCC)

  9. #9
    Registered User
    Join Date
    May 2019
    Posts
    214
    Well, if you have the source for the DLL, you can likely produce a static version of that library, then link statically with it.

    Otherwise, you can DYNAMICALLY link to the DLL (load it implicitly or manually) at runtime.

    While @stahta01 is right that there is some preference for DLL's among many programmers, many of us prefer static linking where possible as it simplifies development.

    Now, about the libs.

    A static lib will generate what is basically a package of object files, and the extension is often .lib. A linker can be configured to produce an executable, a static library or a dynamic library. They are all valid output targets. The specifics differ for every compiler.

    When you produce a dynamic library, the extension for Windows is usually DLL, but it could be anything. Plugins, for example, often use some application defined extension, but it is the same binary concept - a dynamic library of compiled code.

    Static libs, on the other hand, are merely packaged object files and link just like any collection of object files produced from individual translation units.

    For the dynamic library you have an additional layer of complexity. If there is an import library, the process can automatically perform dynamic linking at runtime - which is to say the running executable will "know" what functions are in the DLL. However, without that, the running executable will not know, automatically, what functions are in the DLL, which means they must be "discovered" - a process of getting the function pointer and assigning them during runtime during the loading process.

    You'll need to practice that on a simple application contrived for the purpose of understanding how it's done.

  10. #10
    Registered User
    Join Date
    May 2009
    Posts
    4,183
    Quote Originally Posted by samGwilliam View Post
    Do you mean statically link to a DLL (as in go to the compiler options and set the path containing the DLL, as opposed to the compiled app looking for the DLL at runtime)? The problem I'm having is that the project won't build, so that's the only choice I have (assuming that that's even a thing). I'll give it a try...
    You can only dynamically link to an DLL.

    Tim S.
    "...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 09-09-2017, 01:46 AM
  2. Replies: 3
    Last Post: 01-09-2016, 04:21 PM
  3. Recovering Code::Blocks C++ linker settings
    By FortranLevelC++ in forum C++ Programming
    Replies: 16
    Last Post: 12-04-2014, 04:07 PM
  4. Simple include issue with code::blocks
    By KBriggs in forum C Programming
    Replies: 9
    Last Post: 05-02-2014, 01:46 PM
  5. Compiler/Linker work around
    By erry in forum C Programming
    Replies: 4
    Last Post: 06-23-2010, 10:34 PM

Tags for this Thread