I am trying to compile an example code from the MLT Framework website that shows how consumer/producer work. The code is as follows:
#include <stdio.h>
#include <unistd.h>
#include <framework/mlt.h>
int main( int argc, char *argv[] )
{
// Initialise the factory
if ( mlt_factory_init( NULL ) == 0 )
{
// Create the default consumer
mlt_consumer hello = mlt_factory_consumer( NULL, NULL );
// Create via the default producer
mlt_producer world = mlt_factory_producer( NULL, argv[ 1 ] );
// Connect the producer to the consumer
mlt_consumer_connect( hello, mlt_producer_service( world ) );
// Start the consumer
mlt_consumer_start( hello );
// Wait for the consumer to terminate
while( !mlt_consumer_is_stopped( hello ) )
sleep( 1 );
// Close the consumer
mlt_consumer_close( hello );
// Close the producer
mlt_producer_close( world );
// Close the factory
mlt_factory_close( );
}
else
{
// Report an error during initialisation
fprintf( stderr, "Unable to locate factory modules\n" );
}
// End of program
return 0;
}
The file name is player.c.
I cannot use make to compile it with make player as it does not find include files.
I am using the following command to compile with gcc:
# gcc -I /usr/include/mlt -l libmltcore -o player player.c
/usr/bin/ld: cannot find -llibmltcore
collect2: error: ld returned 1 exit status
As you can see the linker cannot find the mlt library. OS is Fedora 32 and I have installed mlt-devel and I am sure I have the following libs in /usr/lib64/mlt:
libmltavformat.so libmltlinsys.so libmltqt.so libmltvidstab.so
libmltcore.so libmltmotion_est.so libmltresample.so libmltvmfx.so
libmltdecklink.so libmltnormalize.so libmltrtaudio.so libmltvorbis.so
libmltfrei0r.so libmltoldfilm.so libmltsdl2.so libmltxml.so
libmltgtk2.so libmltopengl.so libmltsdl.so
libmltjackrack.so libmltplusgpl.so libmltsox.so
libmltkdenlive.so libmltplus.so libmltvideostab.so
What am I doing wrong?
My second question is why does GCC not find the include files and libraries in the first place so that I have to specify them manually?
regarding:
gcc -I /usr/include/mlt -l libmltcore -o player player.c`
The linker handles things in the order they are listed on the command. So when the linker encounters -l libmitcore there are no unresolved external references so nothing is included so in the end the link step will fail. Suggest:
gcc player.c -o player -I /usr/include/mlt -l libmltcore
regarding:
/usr/bin/ld: cannot find -llibmltcore
if the libmltcore is not on one of the 'standard' library directories, it will not be found, UNLESS the command also includes the library path. Suggest including the following parameter, before the library name:
-L /usr/lib64/mlt
Related
I am using dlsym to look up symbols in my program, but it always returns NULL, which I am not expecting. According to the manpage, dlsym may return NULL if there was an error somehow, or if the symbol indeed is NULL. In my case, I am getting an error. I will show you the MCVE I have made this evening.
Here is the contents of instr.c:
#include <stdio.h>
void * testing(int i) {
printf("You called testing(%d)\n", i);
return 0;
}
A very simple thing containing only an unremarkable example function.
Here is the contents of test.c:
#include <dlfcn.h>
#include <stdlib.h>
#include <stdio.h>
typedef void * (*dltest)(int);
int main(int argc, char ** argv) {
/* Declare and set a pointer to a function in the executable */
void * handle = dlopen(NULL, RTLD_NOW | RTLD_GLOBAL);
dlerror();
dltest fn = dlsym(handle, "testing");
if(fn == NULL) {
printf("%s\n", dlerror());
dlclose(handle);
return 1;
}
dlclose(handle);
return 0;
}
As I step through the code with the debugger, I see the dlopen is returning a handle. According to the manpage, If filename is NULL, then the returned handle is for the main program. So if I link a symbol called testing into the main program, dlsym should find it, right?
Here is the way that I am compiling and linking the program:
all: test
instr.o: instr.c
gcc -ggdb -Wall -c instr.c
test.o: test.c
gcc -ggdb -Wall -c test.c
test: test.o instr.o
gcc -ldl -o test test.o instr.o
clean:
rm -f *.o test
And when I build this program, and then do objdump -t test | grep testing, I see that the symbol testing is indeed there:
08048632 g F .text 00000020 testing
Yet the output of my program is the error:
./test: undefined symbol: testing
I am not sure what I am doing wrong. I would appreciate if someone could shed some light on this problem.
I don't think you can do that, dlsym works on exported symbols. Because you're doing dlsym on NULL (current image), even though the symbols are present in the executable ELF image, they're not exported (since it's not a shared library).
Why not call it directly and let the linker take care of it? There's no point in using dlsym to get symbols from the same image as your dlsym call. If your testing symbol was in a shared library that you either linked against or loaded using dlopen then you would be able to retrieve it.
I believe there's also a way of exporting symbols when building executables (-Wl,--export-dynamic as mentioned in a comment by Brandon) but I'm not sure why you'd want to do that.
I faced the similar issue in my code.
I did the following to export symbols
#ifndef EXPORT_API
#define EXPORT_API __attribute__ ((visibility("default")))
#endif
Now for each of the function definition I used the above attribute.
For example the earlier code was
int func() { printf(" I am a func %s ", __FUNCTION__ ) ;
I changed to
EXPORT_API int func() { printf(" I am a func %s ", __FUNCTION__ ) ;
Now it works.
dlsym gives no issues after this.
Hope this works for you as well.
I wrote a small c file to test DRMAA but it keeps telling me that the DRMAA functions I used are not defined. I included the drmaa.h file in the C code. When I use -idrmaa I get this error:
[mkatouzi#argo-1 ~]$ cc -o drmtest -I$SGE_ROOT/include/ -ldrmaa -ldl drmtest.c
/usr/bin/ld: cannot find -ldrmaa
the DRMAA header file is in this path: $SGE_ROOT/include/
If I compile the file without -ldrmaa I get this error:
[mkatouzi#argo-1 ~]$ cc -o drmtest -I$SGE_ROOT/include/ drmtest.c
/tmp/cclsPr9O.o: In function `main':
drmtest.c:(.text+0x3c): undefined reference to `drmaa_init'
drmtest.c:(.text+0x83): undefined reference to `drmaa_exit'
collect2: ld returned 1 exit status
I am using my school's UNIX system and I am very new to it. Can anyone help me with this?
This is my drmtest.c file:
#include <stdio.h>
#include "drmaa.h"
int main (int argc, char **argv) {
char error[DRMAA_ERROR_STRING_BUFFER];
int errnum = 0;
errnum = drmaa_init (argv[0], error, DRMAA_ERROR_STRING_BUFFER);
if (errnum != DRMAA_ERRNO_SUCCESS) {
fprintf (stderr, "Couldn't init DRMAA library: %s\n", error);
return 1; }
/* Do Stuff */
errnum = drmaa_exit (error, DRMAA_ERROR_STRING_BUFFER);
if (errnum != DRMAA_ERRNO_SUCCESS) {
fprintf (stderr, "Couldn't exit DRMAA library: %s\n", error);
return 1; }
return 0;
}
In the first case, the linker is you telling it does not know where to find the drmaa library. In the second case, since you have not included the drmaa library, the linker is telling you it does not know how to resolve the drmaa functions you are using.
You need to figure out where the drmaa library files are, i.e. in which directory.
Once you know that, you can specify -L/path/to/drmaa/directory when compiling/linking to resolve the problem.
As per Brian Cain's answer, the library (drmaa.a or drmaa.so) is probably under $SGE_ROOT/lib.
Finally, since the directory where the library is stored is not in the system's standard library search path, you have to tell the dynamic linker where to find the library when running the executable. There are two ways to achieve this:
Set (and export) the LD_LIBRARY_PATH environment variable to the library's directory (e.g. $SGE_ROOT/lib)
Or add the -R/path/to/drmaa/directory option when compiling/linking.
You likely need to specify the library path at which libdrmaa.so is found.
e.g.
cc -o drmtest -I$SGE_ROOT/include/ -L$SGE_ROOT/lib/ -ldrmaa -ldl drmtest.c
If you encounter a run-time problem linking against the library, you should check your system configuration.
The LD_LIBRARY_PATH environment variable can be used in a pinch, but on many modern systems you can/should use ld.so.conf.
e.g.
echo <<EOF > /etc/ld.so.conf.d/sge.conf
/usr/sge/lib
EOF
I need to create an application to extract one file from zip archive, after which I want to compile it for Android.
I'm using Ubuntu, with libzip-0.10.1 pre-installed.
I created C project in Eclipse, added include path and found simple script for extracting file. Unfortunately I cannot get the following to build and I could use some advice.
// zip.c file
#include <stdio.h>
#include <stdlib.h>
#include <zip.h>
int main(int argc, char **argv) {
struct zip *zip_file;
struct zip_file *file_in_zip;
int err;
int files_total;
int file_number;
int r;
char buffer[10000];
if (argc < 3) {
fprintf(stderr,"usage: %s <zipfile> <fileindex>\n",argv[0]);
return -1;
};
zip_file = zip_open(argv[1], 0, &err);
if (!zip_file) {
fprintf(stderr,"Error: can't open file %s\n",argv[1]);
return -1;
};
file_number = atoi(argv[2]);
files_total = zip_get_num_files(zip_file);
if (file_number > files_total) {
printf("Error: we have only %d files in ZIP\n",files_total);
return -1;
};
file_in_zip = zip_fopen_index(zip_file, file_number, 0);
if (file_in_zip) {
while ( (r = zip_fread(file_in_zip, buffer, sizeof(buffer))) > 0) {
printf("%s",buffer);
};
zip_fclose(file_in_zip);
} else {
fprintf(stderr,"Error: can't open file %d in zip\n",file_number);
};
zip_close(zip_file);
return 0;
};
Also I added few .h files to include directory in my project and few .c files to directory with zip.c file. After that all dependences was good, but I have an error:
‘struct zip’ has no member named ‘default_password’ in file zip_fopen_index.c
The file zip_fopen_index.c is:
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include "zipint.h"
ZIP_EXTERN struct zip_file *
zip_fopen_index(struct zip *za, zip_uint64_t fileno, int flags)
{
return zip_fopen_index_encrypted(za, fileno, flags, za->default_password); // error here
}
First of all allow me some comments:
Your program is not compiled and linked by Eclipse.
Compiling is done by the compiler (gcc using option -c):
make all
Building file: ../zip.c
Invoking: GCC C Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"zip.d" -MT"zip.d" -o "zip.o" "../zip.c"
Finished building: ../zip.c
Linking is done by the linker (via the compiler using option -o):
Invoking: GCC C Linker
gcc -o "unzipper" ./zip.o
./main.o: In function `zip':
/home/alk/workspace/unzipper/Debug/../zip.c:20: undefined reference to `zip_open'
/home/alk/workspace/unzipper/Debug/../zip.c:27: undefined reference to `zip_get_num_files'
/home/alk/workspace/unzipper/Debug/../zip.c:33: undefined reference to `zip_fopen_index'
/home/alk/workspace/unzipper/Debug/../zip.c:35: undefined reference to `zip_fread'
/home/alk/workspace/unzipper/Debug/../zip.c:38: undefined reference to `zip_fclose'
/home/alk/workspace/unzipper/Debug/../zip.c:43: undefined reference to `zip_close'
collect2: ld returned 1 exit status
Eclipse provides a framework helping you in managing all sources and their references as also spawing compiler and linker tasks and setting their options.
When the linker told you there where undefined references to the zip_*function during the build of your program, the cause for this was, you were missing to tell the linker (via the compiler, via Eclipse) where those zip_* functions could be found.
Those zip_* functions are located in a library, namely libzip.
So what you as the programmer need to tell the linker (via the compiler, via Eclipse) is to link those functions against what the compiler compiled from your sources.
As the result the linker is able to create a runnable program from your compiled sources together with all libraries needed. Certain libraries are know to Eclipse (and therfore to the linker) by default, for example the one containing the C standard functions, namely libc.
To get things going:
1 Remove the source files you pulled from the libzip librarie's sources from your project. Those sources had been compiled into the library libzip, which you will use in your project.
2 Tell the linker (via Eclipse) to use libzip for your project.
Do so by following the steps below:
open the project's properties
click 'C/C++ General'
click 'Path and Symbols', on the left select the 'Libraries' tab, there click 'Add' and enter zip
finally click 'OK'
3 Then try to build your program:
Building target: unzipper
Invoking: GCC C Linker
gcc -o "unzipper" ./zip.o -lzip
Finished building target: unzipper
(Please note additional option -lzip!)
If the developement version of 'libzip' had been installed properly before, you should be fine.
PS: unzipper was the name I used for the Eclispe project to produce the examples.
PSS: I used Eclipse Juno SR1
I am a unskilled programmer and new to linux, I run into a problem when complining. I have two files 'ex_addinst.c' and 'lindo.h' in the same folder, I input command :
g++ -c ex_addinst.c
then, a object file ex_addinst.o is genetated with a warning:
ex_addinst.c: In function ‘int main()’:
ex_addinst.c:80: warning: deprecated conversion from string constant to ‘char*’
then I leak them with
g++ -Wall -o ex_addinst ex_addinst.o
and get the following info:
ex_addinst.o: In function `main':
ex_addinst.c:(.text+0x2b): undefined reference to `LSloadLicenseString'
ex_addinst.c:(.text+0x75): undefined reference to `LSgetVersionInfo'
ex_addinst.c:(.text+0xae): undefined reference to `LScreateEnv'
ex_addinst.c:(.text+0x10a): undefined reference to `LSgetErrorMessage'
...
...
ex_addinst.c:(.text+0x1163): undefined reference to `LSdeleteEnv'
collect2: ld returned 1 exit status
I guess that the header file 'lindo.h' is not complied into the .o file, but I have no idea what to do now. I have tried gcc, but get the same error. the version of my g++ and gcc is 4.4.5. I am using Ubuntu 10.10.
All the functions and structures have been declared in 'lindo.h'.
part of ex_addinst.c is as follows:
#include <stdio.h>
#include <stdlib.h>
/* LINDO API header file */
#include "lindo.h"
enter code here
int CALLTYPE LSwriteMPIFile(pLSmodel pModel,
char *pszFname);
/* Define a macro to declare variables for
error checking */
#define APIERRORSETUP \
int nErrorCode; \
char cErrorMessage[LS_MAX_ERROR_MESSAGE_LENGTH] \
/* Define a macro to do our error checking */
#define APIERRORCHECK \
if (nErrorCode) \
{ \
if ( pEnv) \
{ \
LSgetErrorMessage( pEnv, nErrorCode, \
cErrorMessage); \
printf("nErrorCode=%d: %s\n", nErrorCode, \
cErrorMessage); \
} else {\
printf( "Fatal Error\n"); \
} \
exit(1); \
} \
#define APIVERSION \
{\
char szVersion[255], szBuild[255];\
LSgetVersionInfo(szVersion,szBuild);\
printf("\nLINDO API Version %s built on %s\n",szVersion,szBuild);\
}\
/* main entry point */
int main()
{
APIERRORSETUP;
pLSenv pEnv;
pLSmodel pModel;
char MY_LICENSE_KEY[1024];
/*****************************************************************
* Step 1: Create a model in the environment.
*****************************************************************/
nErrorCode = LSloadLicenseString("home/li/work/tools/lindo/lindoapi/license/lndapi60.lic", MY_LICENSE_KEY);
if ( nErrorCode != LSERR_NO_ERROR)
{
printf( "Failed to load license key (error %d)\n",nErrorCode);
exit( 1);
}
......
......
......
APIERRORCHECK;
{
int nStatus;
double objval=0.0, primal[100];
/* Get the optimization result */
nErrorCode = LSgetInfo(pModel, LS_DINFO_GOP_OBJ, &objval);
APIERRORCHECK;
LSgetMIPPrimalSolution( pModel, primal) ;
APIERRORCHECK;
printf("\n\nObjective = %f \n",objval);
printf("x[0] = %f \n",primal[0]);
printf("x[1] = %f \n",primal[1]);
/* Get the linearity of the solved model */
nErrorCode = LSgetInfo (pModel, LS_IINFO_GOP_STATUS, &nStatus);
APIERRORCHECK;
/* Report the status of solution */
if (nStatus==LS_STATUS_OPTIMAL || nStatus==LS_STATUS_BASIC_OPTIMAL)
printf("\nSolution Status: Globally Optimal\n");
else if (nStatus==LS_STATUS_LOCAL_OPTIMAL)
printf("\nSolution Status: Locally Optimal\n\n");
else if (nStatus==LS_STATUS_INFEASIBLE)
printf("\nSolution Status: Infeasible\n\n");
}
/* >>> Step 7 <<< Delete the LINDO environment */
LSdeleteEnv(&pEnv);
/* Wait until user presses the Enter key */
printf("Press <Enter> ...");
getchar();
}
part of 'lindo.h' is:
/*********************************************************************
* Structure Creation and Deletion Routines (4) *
*********************************************************************/
pLSenv CALLTYPE LScreateEnv(int *pnErrorcode,
char *pszPassword);
pLSmodel CALLTYPE LScreateModel(pLSenv pEnv,
int *pnErrorcode);
int CALLTYPE LSdeleteEnv(pLSenv *pEnv);
int CALLTYPE LSdeleteModel(pLSmodel *pModel);
int CALLTYPE LSloadLicenseString(char *pszFname, char *pachLicense);
void CALLTYPE LSgetVersionInfo(char *pachVernum, char *pachBuildDate);
Thank you!
Thank you guys answering my problem. As you suggested, I need to link the library when complining. I have gotten the executable file with:
gcc -o ex_addinst ./ex_addinst.o -L/home/li/work/tools/lindo/lindoapi/bin/linux64 -m64 -llindo64 -lmosek64 -lconsub3 -lc -ldl -lm -lguide -lpthread -lsvml -limf -lirc
but there comes another problem when run the executable file ex_addinst: after run:
./ex_addinst
there comes:
./ex_addinst: error while loading shared libraries: liblindo64.so.6.0: cannot open shared object file: No such file or directory
The tricky thing is, liblindo64.so.6.0 is in the lib folder which contains:
libconsub3.so libirc.so liblindojni.so libmosek64.so.5.0 lindo.par
libguide.so liblindo64.so liblindojni.so.6.0.3 libsvml.so placeholder
libimf.so liblindo64.so.6.0 libmosek64.so lindoapivars.sh runlindo
I have created symbolic links between liblindo64.so.6.0 and liblindo64.so with
ln -sf liblindo64.so.6.0 liblindo64.so
but it doesn't help.
Can anyone tell me what is wrong here?
(I am not sure I should put this question in a new post, but I think currently it is better to follow the old one)
Ok, lindo.h contains the prototypes for those functions, but where are the functions actually defined? If they're in another C file you need to compile that one too, and link both the object files together.
If the functions are part of another static library, you need to tell the linker to link that library along with your object file.
If they're defined with a shared library, you can probably get g++ to still link to it at compile time, and take care of the library loading etc. Otherwise you'll need to load the library at runtime and reference the functions from the library. This Wikipedia article on dynamic loading of shared libraries contains some example code.
Try
g++ -Wall -o ex_addinst ex_addinst.c
instead of
g++ -Wall -o ex_addinst ex_addinst.o
You want to compile the .c file, not the .o file.
You need to tell gcc to link with the library or object file(s) that contain the LS... functions you're using. The header file tells the compiler how to call them, but the linker needs to know where to get the compiled code from.
undefined reference to ... is not a declaration problem. The compiler fails because it can't find symbols (objects) which are related to those declared functions.
In your case, you use the Limbo API, and include the header file, but you don't tell the compiler to link with the library : that's why it doesn't find symbols.
EDIT : I had forgotten the part when you say you're new to Linux. To link with the library, you need to use the -L/-l options of g++. man g++ is always a good read, and the Limbo's documentation should be, too.
i am trying to compile this code, but if i do using:
gcc prt.c portaudio.h -o prt
but i get this error:
main.c:47: undefined reference to `Pa_OpenDefaultStream'
main.c:62: undefined reference to `Pa_StartStream'
main.c:65: undefined reference to `Pa_Sleep'
main.c:66: undefined reference to `Pa_StopStream'
main.c:69: undefined reference to `Pa_CloseStream'
main.c:72: undefined reference to `Pa_Terminate'
main.c:78: undefined reference to `Pa_Terminate'
i don't know why, then i though it might be beacuse i don't have a rule (make file)
so i made one:
main: main.o
gcc main.o -o main
main.o: main.c portaudio.h
gcc -c main.c
but when i try to run it through cygwin: using "Make"
i get this message:
"make: *** No targets specified and no makefile found. Stop.
I don't understand the problem, please help me is something wrong with my makefile or is there something else wrong.
also this is the code:
main.c
#include <stdio.h>
#include "portaudio.h"
#define SAMPLE_RATE (44100)
typedef struct
{
float left_phase;
float right_phase;
}
paTestData;
static int patestCallback( const void *inputBuffer, void *outputBuffer,
unsigned long framesPerBuffer,
const PaStreamCallbackTimeInfo* timeInfo,
PaStreamCallbackFlags statusFlags,
void *userData )
{
/* Cast data passed through stream to our structure. */
paTestData *data = (paTestData*)userData;
float *out = (float*)outputBuffer;
unsigned int i;
(void) inputBuffer; /* Prevent unused variable warning. */
for( i=0; i<framesPerBuffer; i++ )
{
*out++ = data->left_phase; /* left */
*out++ = data->right_phase; /* right */
/* Generate simple sawtooth phaser that ranges between -1.0 and 1.0. */
data->left_phase += 0.01f;
/* When signal reaches top, drop back down. */
if( data->left_phase >= 1.0f ) data->left_phase -= 2.0f;
/* higher pitch so we can distinguish left and right. */
data->right_phase += 0.03f;
if( data->right_phase >= 1.0f ) data->right_phase -= 2.0f;
}
return 0;
}
static paTestData data;
int main (void) {
PaStream *stream;
PaError err;
err = Pa_OpenDefaultStream( &stream,
0, /* no input channels */
2, /* stereo output */
paFloat32, /* 32 bit floating point output */
SAMPLE_RATE,
256, /* frames per buffer, i.e. the number
of sample frames that PortAudio will
request from the callback. Many apps
may want to use
paFramesPerBufferUnspecified, which
tells PortAudio to pick the best,
possibly changing, buffer size.*/
patestCallback, /* this is your callback function */
&data ); /*This is a pointer that will be passed to
your callback*/
err = Pa_StartStream( stream );
if( err != paNoError ) goto error;
Pa_Sleep(9*1000);
err = Pa_StopStream( stream );
if( err != paNoError ) goto error;
err = Pa_CloseStream( stream );
if( err != paNoError ) goto error;
err = Pa_Terminate( );
if( err != paNoError ) goto error;
printf("Test finished.\n");
return err;
error:
Pa_Terminate();
return err;
}
and the header file portaudio.h: Portaudio.h
if you want cleaner view of main.c: main.c
I am not so sure why these messages/errors/warning are coming, please help.
also this is my folder view:
You seem to be using functions from a library for the 'Port Audio' facility, but your link line does not tell the C compiler how to find that library - so the functions show up as undefined references.
Your link line should look something like:
gcc -o main main.o -lpa
That should be macroized, but the gist is correct.
This assumes the library is in 'libpa.a' or thereabouts. If it is in 'libportaudio.so', then use -lportaudio instead of -lpa.
Using macros in the makefile:
PROGRAM = main
SOURCE = main.c
OBJECT = $(SOURCE:.c=.o)
LIBDIR = /cygdrive/c/installdir/portaudio/lib
LIBRARY = $(LIBDIR)/portaudio_x86.lib
$(PROGRAM): $(OBJECT)
$(CC) $(CFLAGS) -o $# $(OBJECT) $(LDFLAGS) $(LIBRARY)
main.o: main.c portaudio.h
You should not need an explicit compilation command for main.o; make should be able to deduce that from its internal rules. Note that the character before $(CC) must be a TAB and not spaces.
The make command only looks for a file called makefile or Makefile, to use make with a differently named makefile, you need to do make -f otherfile target.
Rename your file Make file to Makefile to have make look at its contents. Also, verify that you use one tab character (no spaces) in all of the commands under a target. You might have done that, but your cut-and-paste of the contents in this posting doesn't let us know if that is really how it is.
It would also appear that you need the PortAudio library to link to or those functions will not be defined. That is, unless they're defined in the header (I haven't used that library before...)
Did portaudio come with a .lib or anything? The header file only contains the name of the functions, not the definitions. You'll need to link against the library to get the functionality for all of those functions
Your initial problem ("Undefined reference to...") is a message from the linker saying it cannot find a definition of the functions mentioned. This means you need to add a linker argument saying that you want to add the library providing these functions (lib portaudio?) to your program. GCC's command line parameter to do so is "-l"
It seems like you need to include the library (with a -l[library name] option.
A search of portaudio compile commands shows libportaudio.a included in the gcc options.
You are probably not linking to those libraries libs (.so or .a) look at the documentation and see what libs you need to link your program with.
The other thing is that when you run "make -f Makefile" you need to have a tab in your makefile before the "gcc..." lines i.e. the command lines.
I also need to add -lm, otherwise it throws an error.
So gcc -o test test.c -lm -lportaudio