If I am to link up a precompiled library I must...
1) place the library object file in dev-cpps lib folder.
2) place the includes in the includes folder (create a subfolder and put them in there ideally).
3) put the .dll's in the bin folder.Or the dll folder ?
4) add the path to the linker field under project options -> parameters
5) #include the header file.
I recently started with a fresh install of SDL and pdCurses with dev-cpp (4.9.9.2) via the download manager (dev-paks.org server).
After cleanly reinstalling dev-cpp 4.9.9.2.
After dev-cpp automatically installed them I needed to move some of the dll's to the bin folder because they were'nt being detected in the dll folder (where they were placed by the program).
Soon I had multiple copies of the same dll/s strewn about the dev-cpp directory so I felt I should redo it all again.
Can you add anything to my solution,like where I'm going wrong.
I dont want to go through all this again and end up in the same state.
respectfully yours.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> 1) place the library object file in dev-cpps lib folder.
Not necessarily, but that is one way. Any folder specified by a -L<path> option will do. You can add your own in either the project options, or teh general compiler options (then applied to every project). There is a strong argument for keeping additional libraries in a folder separate from the default Dev-C++ installation (in case of a reinstall or upgrade). Alternatively you need not do that at all since you can specify a library and its path directly (click the Add Object File or Library... button in the project options), this is simplest when you are only linking one additional library.
>> 2) place the includes in the includes folder (create a subfolder and put them in there ideally).
That is,I would argue an even worse idea that placing additional libraries in c:\dev-cpp\lib. You can do that, but again you can specify your own location with a -I<path> option (also available in the project and general compiler options).
>> 3) put the .dll's in the bin folder.Or the dll folder ?
If the library is a DLL it needs to be placed in a folder listed in the system PATH environment variable, or in teh same folder as the executable. If your application is the only thing likely to be using the DLL, the latter is probably preferable, it reduces the chances of your DLL overriding one of the same name already in the system or vice versa. Either way, the common habit of dumping all DLLs in c:\windows\system32 is mostly annoying (to users installing your application), and can potentially break other applications.
>> 4) add the path to the linker field under project options -> parameters
If you did (1) you need not add the path. By convention GNU libraries (or archives) are named libXXX.a and are linked with -lXXX (the lib prefix and .a extension are assumed). BTW the button I mentioned in (1) is on teh same dialog you mentioned in (4) ...its a big clue!
>> 5) #include the header file.
You got that part right. You could also specify a path here and omit (2) or adding a -I<path>. If you use "file.h" rather than <file.h>, the header may also be placed in the same folder as the source.
>> Can you add anything to my solution,like where I'm going wrong.
Most Dev-Paks include a project template that set the necessary compiler/linker options for you. Did you use the provided template? The location of a DLL is more to do with deployment than building, it is a runtime issue not a build issue. The simplest solution is to keep a copy of the DLL with the executable. For development, add the path to the DLLs to teh PATH environment variable (right-click My Computer, select Properties->Advanced->Environment variables, select PATH and edit it). If you distribute your application, the DLL will have to be distributed too. The problem is to avoid overwriting any existing DLL the user may already have installed for other applications, which is why having a private copy with your executable is preferable unless it is a well known system provided DLL that you can reasonably expect to be installed on all systems (basically these are part of the OS), or if you are going to distribute multiple SDL applications that could share teh same copy of the DLL. All that is down to how you install the final distribution.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can I get some confirmation here please.
If I am to link up a precompiled library I must...
1) place the library object file in dev-cpps lib folder.
2) place the includes in the includes folder (create a subfolder and put them in there ideally).
3) put the .dll's in the bin folder.Or the dll folder ?
4) add the path to the linker field under project options -> parameters
5) #include the header file.
I recently started with a fresh install of SDL and pdCurses with dev-cpp (4.9.9.2) via the download manager (dev-paks.org server).
After cleanly reinstalling dev-cpp 4.9.9.2.
After dev-cpp automatically installed them I needed to move some of the dll's to the bin folder because they were'nt being detected in the dll folder (where they were placed by the program).
Soon I had multiple copies of the same dll/s strewn about the dev-cpp directory so I felt I should redo it all again.
Can you add anything to my solution,like where I'm going wrong.
I dont want to go through all this again and end up in the same state.
respectfully yours.
I read it last year.
I'll read it again then.
>> 1) place the library object file in dev-cpps lib folder.
Not necessarily, but that is one way. Any folder specified by a -L<path> option will do. You can add your own in either the project options, or teh general compiler options (then applied to every project). There is a strong argument for keeping additional libraries in a folder separate from the default Dev-C++ installation (in case of a reinstall or upgrade). Alternatively you need not do that at all since you can specify a library and its path directly (click the Add Object File or Library... button in the project options), this is simplest when you are only linking one additional library.
>> 2) place the includes in the includes folder (create a subfolder and put them in there ideally).
That is,I would argue an even worse idea that placing additional libraries in c:\dev-cpp\lib. You can do that, but again you can specify your own location with a -I<path> option (also available in the project and general compiler options).
>> 3) put the .dll's in the bin folder.Or the dll folder ?
If the library is a DLL it needs to be placed in a folder listed in the system PATH environment variable, or in teh same folder as the executable. If your application is the only thing likely to be using the DLL, the latter is probably preferable, it reduces the chances of your DLL overriding one of the same name already in the system or vice versa. Either way, the common habit of dumping all DLLs in c:\windows\system32 is mostly annoying (to users installing your application), and can potentially break other applications.
>> 4) add the path to the linker field under project options -> parameters
If you did (1) you need not add the path. By convention GNU libraries (or archives) are named libXXX.a and are linked with -lXXX (the lib prefix and .a extension are assumed). BTW the button I mentioned in (1) is on teh same dialog you mentioned in (4) ...its a big clue!
>> 5) #include the header file.
You got that part right. You could also specify a path here and omit (2) or adding a -I<path>. If you use "file.h" rather than <file.h>, the header may also be placed in the same folder as the source.
>> Can you add anything to my solution,like where I'm going wrong.
Most Dev-Paks include a project template that set the necessary compiler/linker options for you. Did you use the provided template? The location of a DLL is more to do with deployment than building, it is a runtime issue not a build issue. The simplest solution is to keep a copy of the DLL with the executable. For development, add the path to the DLLs to teh PATH environment variable (right-click My Computer, select Properties->Advanced->Environment variables, select PATH and edit it). If you distribute your application, the DLL will have to be distributed too. The problem is to avoid overwriting any existing DLL the user may already have installed for other applications, which is why having a private copy with your executable is preferable unless it is a well known system provided DLL that you can reasonably expect to be installed on all systems (basically these are part of the OS), or if you are going to distribute multiple SDL applications that could share teh same copy of the DLL. All that is down to how you install the final distribution.
Clifford
That helps me tremendously Clifford.
Thank you.
Linking libraries has been a bane of my existence until now.
respects.
Out of curiosity, had you read the section in the "Please Read" thread on the compile log, including headers and linking libraries?
Wayne