unusual linker error Portaudio
I attempted to compile the portaudio code examples with gcc in the command line. I know that if the something is defined externally the linker needs to be able to find where the definition "lives". Normally if the program and the header are located in the same directory the definitions are easily resolved. Compiling a program without resolved definitions resolves in "undefined". The API definitions live in the header file "portaudio.h". What is strange is that even after placing both the intended program to be compiled and the header API definitions in the same directory, and passing them both as arguments; the linker does not seem to recognize that everything has been defined. This is the only situation where I have had this happen, where I expected the header file definitions to be seen by the linker and they some how were not. What could be going on?
Last edited on
There is a difference between the concept of a definition and a declaration.
I've looked at the Portaudio.h file from the library.
It contains declarations, but almost nothing of definitions.
That is probably what the linker is complaining about. The rest of the code, which provides the definitions, is elsewhere in the library source, and I doubt you've included THAT for the linker to find, hence it complains about undefined functions which are merely declared in that header file.
I've looked at the Portaudio.h file from the library.
It contains declarations, but almost nothing of definitions.
That is probably what the linker is complaining about. The rest of the code, which provides the definitions, is elsewhere in the library source, and I doubt you've included THAT for the linker to find, hence it complains about undefined functions which are merely declared in that header file.
This is circular. I look for where the portaudio API definitions are and only find declarations. The documentation tells me they are defined and then I go to compile the program with the header and then the linker tells me they are not defined. What am I missing? Do I override the declarations for each different OS? I'm really stuck.
Take a few entries one a time and discover:
For example, the first declared function in portaudio.h is Ps_GetVersion()
It is only a declaration, not a definition. Searching the directory for the text I find the definition is written in pa_front.c, and as I'd expect a few other functions are defined there.
pa_front.c is in a directory called src, which is typical of many projects. This means the source files, which contain the definitions, are probably all located there.
Have you done anything which would compiles these files so the linker would find them?
Have you followed the build instructions in the documentation?
That's part of the problem, this isn't true. The include directory contains only the header files but few if any definitions. Depending on the documentation's instructions, there may be project or make files you need to process in order to build the appropriate library (perhaps a static library, I haven't reviewed).
For example, I downloaded the project for a quick look and found that in the build directory there are solution files for Visual Studio, which define the project for building.
It is important to build according to the instructions particularly for a library like this because it is portable, intended for many operating systems, and the build is configured for a particular target.
It appears they have support for CMake, so depending on your compiler and platform target(s), you may be best advised to use CMake for building.
For example, the first declared function in portaudio.h is Ps_GetVersion()
It is only a declaration, not a definition. Searching the directory for the text I find the definition is written in pa_front.c, and as I'd expect a few other functions are defined there.
pa_front.c is in a directory called src, which is typical of many projects. This means the source files, which contain the definitions, are probably all located there.
Have you done anything which would compiles these files so the linker would find them?
Have you followed the build instructions in the documentation?
Normally if the program and the header are located in the same directory... |
That's part of the problem, this isn't true. The include directory contains only the header files but few if any definitions. Depending on the documentation's instructions, there may be project or make files you need to process in order to build the appropriate library (perhaps a static library, I haven't reviewed).
For example, I downloaded the project for a quick look and found that in the build directory there are solution files for Visual Studio, which define the project for building.
It is important to build according to the instructions particularly for a library like this because it is portable, intended for many operating systems, and the build is configured for a particular target.
It appears they have support for CMake, so depending on your compiler and platform target(s), you may be best advised to use CMake for building.
Last edited on
Okay, so the include directory holds external declarations. Why would be declare something externally and define it elsewhere? That seems like a waste of time.
@Willogical, actually it's a common organization and not illogical at all. If the objective of the code is to build a static or dynamic library, all other code that consumes it would only need the declarations because the linker would find all of the code in the library.
I got everything built into static libs for windows and the common library. All I had to do was tell the linker about windows multimedia with -lwmm. It worked! I built the pink noise example. I can now go onto writing my own sine-wave generator and maybe add some digital delay. Any advice for working with the VST SDK manually? I want to work almost exclusively by-hand on the command-line to learn more about how code is put together. I think putting in just a little extra trouble can help me feel more in-tune with how things work, and when I go to use an IDE and build automation everything won't seem so mysterious. Should I take the time to learn CMake?
Definitely learn CMake!
While I have no choice but to agree with your logic, after decades of doing this (and from an era when we had little more than "make files" for project management) I'm familiar.
However, don't hold on to it for too long. It is a tedium without much purpose in the 21st century. The time saved by using an IDE for project configuration is well worth it and quite liberating.
Then, just as I say that, I have to turn 180 degrees to acknowledge that an environment like Android Studio basically does not do much of it's own automation for project management, but uses Gradle and sometimes CMake for building.
Many of the IDE's can use CMake, and CMake will build project (solution in VS) files for various IDE's.
In the last decade even Visual Studio's solution and project file format is merely a flavor of XML, so it can be thought of as just another kind of "make" file of sorts. There are times when large refactoring of the project is best done on the Visual Studio project files as text, instead of the "mysterious" settings in dialogs.
It's been a long time since I've used VST SDK, but at that time it seemed tame enough - probably less or no worse than what you just went through.
While I have no choice but to agree with your logic, after decades of doing this (and from an era when we had little more than "make files" for project management) I'm familiar.
However, don't hold on to it for too long. It is a tedium without much purpose in the 21st century. The time saved by using an IDE for project configuration is well worth it and quite liberating.
Then, just as I say that, I have to turn 180 degrees to acknowledge that an environment like Android Studio basically does not do much of it's own automation for project management, but uses Gradle and sometimes CMake for building.
Many of the IDE's can use CMake, and CMake will build project (solution in VS) files for various IDE's.
In the last decade even Visual Studio's solution and project file format is merely a flavor of XML, so it can be thought of as just another kind of "make" file of sorts. There are times when large refactoring of the project is best done on the Visual Studio project files as text, instead of the "mysterious" settings in dialogs.
It's been a long time since I've used VST SDK, but at that time it seemed tame enough - probably less or no worse than what you just went through.
Oh yes. In my career I've worked on audio workstation software, plugins for VST (been a while), a number of "natural reverb" products, "tube" effects, some while consulting for video and film post production products and studios, plugins for Maya and 3DS Max (and what was known as Soft Image), but lately I'm more into physics engines and mobile game engines as well as game development, but with a diversion into robotics (I volunteer to teach at a robotics club at the local high school).
These things overlap a lot, too, because physics engines are used in MAX and Maya, they have audio channels to contend with, games have real time audio systems (often with "3D" placement, even in surround sound), and I'm both a user/consumer and developer of just about any of it along the way. Game engines, when properly tuned, are a "low but reasonable" fidelity of physics simulation for the robotics club...
...and there's stuff I've forgotten until I start thinking about it. I worked on the simulation of an FM synth, and for some reason I got dragged into a project to fit digital sampling synths into an ancient (150+ year old) organ console (a pipe organ), so instead of spending nearly 1 million on actual pipes to expand the instrument, they expanded through sampling. That was the end of the 20th, beginning of the 21st century (the institute 'revealed' the instrument at a concert in January, 2001).
In my youth I was a classically trained violinist, but post 30 I just don't have time to do that anymore, and that was over 25 years ago ;), so naturally music workstations and audio workstations are among my interests and, occasionally, the targets of programming.
An old guy like me finds tendrils of memories recounting that. I high school buddy of mine learned programming at high school, but didn't have a computer, so he would write on my 6502 machine. He was a natural math student, though we lost contact for a decade or more. We reconnected about 20 years ago when I was working on a natural reverb algorithm (independent of an actual product at that time), and then we lost touch again for a few years. Then, one day in about 2004 I find a range of products with his last name in the brand, and come to discover that he took from our discussion (not stealing mind you, just inspiration) the notion to study C++ and create a product line of VST products, including a natural reverb (of completely independent algorithmic development).
These things overlap a lot, too, because physics engines are used in MAX and Maya, they have audio channels to contend with, games have real time audio systems (often with "3D" placement, even in surround sound), and I'm both a user/consumer and developer of just about any of it along the way. Game engines, when properly tuned, are a "low but reasonable" fidelity of physics simulation for the robotics club...
...and there's stuff I've forgotten until I start thinking about it. I worked on the simulation of an FM synth, and for some reason I got dragged into a project to fit digital sampling synths into an ancient (150+ year old) organ console (a pipe organ), so instead of spending nearly 1 million on actual pipes to expand the instrument, they expanded through sampling. That was the end of the 20th, beginning of the 21st century (the institute 'revealed' the instrument at a concert in January, 2001).
In my youth I was a classically trained violinist, but post 30 I just don't have time to do that anymore, and that was over 25 years ago ;), so naturally music workstations and audio workstations are among my interests and, occasionally, the targets of programming.
An old guy like me finds tendrils of memories recounting that. I high school buddy of mine learned programming at high school, but didn't have a computer, so he would write on my 6502 machine. He was a natural math student, though we lost contact for a decade or more. We reconnected about 20 years ago when I was working on a natural reverb algorithm (independent of an actual product at that time), and then we lost touch again for a few years. Then, one day in about 2004 I find a range of products with his last name in the brand, and come to discover that he took from our discussion (not stealing mind you, just inspiration) the notion to study C++ and create a product line of VST products, including a natural reverb (of completely independent algorithmic development).
Last edited on
Nice! I would like to pick your brain on a few things, If you would be willing to listen to my questions. My first hiccup has to do with understanding complex sinusoids and eulers notation. Why use complex notation? If you could please email me at wr7668a@student.american.edu that would be helpful. I would like to build a simple oscillator using a GUI tool kit, and the portaudio library to build a simple modular engine for the audio. I also hope to attend the AES conference in New York this fall. I've really just wanted to get over the hump with building libraries manually so I could understand things better and get away with using a text editor as opposed to an IDE.
I'll email in a moment, but complex numbers themselves imply a 2D graph. It is, in some essence, the description of a rotation, and the the rotation of a vector the complex number describes then defines the complex number system. In the case of complex sinusoids, the idea is to imagine a rotating wheel where the axle is oriented along the X axis of a 2D graph, and as the wheel spins at a constant speed, the wheel itself is moved from, say, left to right. If a "dot on the wheel" were to trace it's path on the 2D graph, the result is a "sine wave", and these two motions define a numeric representation in complex numbers. You can, really, deal with a lot of audio programming without really knowing any of that in a way that resembles how people write 3D games without really understanding quaternion algebra. They just multiply vectors by quaternions as C++ (or C#) objects and accept that the result is a rotated representation. I still look up the math, and once that is interpreted in code, I can happily forget it until I need the reference again. Obvious for more facile requirements, like trigonometry, I have that in mind, but I find myself working in several subjects for which I don't have immediate memory of a particular formula or numerical solution, and I've not found a strong need to steep myself in most of them at any one time, with obvious exceptions occasionally. I know I learned the quadratic formula early in high school, but it has never come up in work. Just a few months ago my son, in high school, had a review question on factoring quadratics into a pair of binomials, and it took me about 10 minutes for the memory to come back. At first I was lost until some tendril of memory was pulled and the rest came back, including that girl on my left (gorgeous) and the nerd on my right that was all bent out of shape because she didn't even know he existed.
I think what you are saying will contextualize itself better once I write more code examples. Let's keep in touch, and I'll keep posting my questions to the forum. Having more people to talk to about this stuff and be treated kindly will be a great asset!
Topic archived. No new replies allowed.