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.

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.

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.

Quote:

---

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.

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.

Quote:

---

Originally Posted by stahta01

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.

Quote:

---

Originally Posted by 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.

---

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

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.

Quote:

---

Originally Posted by stahta01

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...

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.

Quote:

---

Originally Posted by samGwilliam

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.