I am trying to use GLScene (a third-party FireMonkey component for C++Builder and Delphi). I downloaded the zip, and in it, among other things, are .bpl files for use in C++Builder. When I try to install the package in my project (a C++Builder multi-device application) under Component > Install Packages... > Add, I get this error:
My directory structure:
The _Installation directory and the Readme's are not very helpful. I have tried the other .bpl files and also tried importing all of them at once, but the same error occurs. How do I fix this?
There are several problems.
The XE3 extension is suspicious. I just downloaded and unzipped the GLScene download. The .BPLs in the CBXE3 and CBXE4 seem to be compiled for XE3 and XE4 respectively. But packages are version-dependent.
You should recompile the sources (also included) for 10.2 Tokyo. Just copy the DelphiXE4 directory to a new directory, and load the .groupproj file or the single .dpk files into the IDE. You might want to change the suffixes (currently XE3) of the packages to, say, Tokyo, in the project options, to avoid DLL (or BPL) hell.Also take a look at the pictures in the _Installation directory for the other options that must be set. Note that your paths may differ, theirs are just an example.
The compiler needs to be able to find the .bpi and .lib etc. files in order to be able to link. Set the directories with those files in the project options, as shown in the _Installation pictures.
The newly compiled .bpl files should be compiled to a directory on the Windows path, so they can be found by the system at runtime. In their example setup, (and in the _Installation pictures) that is the shown C:\Library\GLScene path.
Related
I am working to build a Code Composer Studio project using cmake, which is new to me. It builds successfully under Linux but I am struggling to get it to work under Windows. The cmake command executes without issue, but make fails during the very first C object at the very first #include with the error code
fatal error: could not open source file "stdbool.h" (no directories in search list)
I'm using the libraries included in CCS's compiler (c6000_7.4.15), and that whole folder is included in the CSS project. I include it in cmake as well. In my .cmake file:
set (CCS_ROOT ${CCS_ROOT_V6_WIN} CACHE PATH "code composer install directory")
set(CGT_COMPILER_ROOT ${CCS_ROOT}/tools/compiler/c6000_7.4.15 CACHE INTERNAL "DSP Compiler Root")`
And in the CMakeLists.txt file:
set (COMPILER_INCLUDE ${CGT_COMPILER_ROOT}/include)
INCLUDE_DIRECTORIES ("${COMPILER_INCLUDE}")
Why can the header files not be opened when they're linked in the project and CMake can find them just fine?
EDIT: The directory structure had been changed underneath me, so I took the opportunity to add all of the external files directly into the project to make it completely platform-independent. That way, since the project is managed by our Git repository, users won't have to install the CSL or any other programs to build the project. This also means that paths to libraries and header files will never change between revisions and environments.
Unfortunately, this has not solved my problem. The project continues to build in Linux while failing to ind the very first included header file. I also notice that, under Windows, it cannot find my own header files unless I provide a relative path, e.g. #include "../Common.h" I can get make to find stdbool.h if I provide an absolute path to the compiler directory, but that exposes a web of additional broken links between files.
As a side note, the project builds successfully within Code Composer Studio, so I am assuming that this isn't an issue with my specific Windows environment nor with the code within the project itself.
This seems to be an issue with gcc.exe. I set an environment variable CC to the path of a different compiler (in my case a TI compiler) within my build script and that fixed the problem.
I have an executable that is generated using VC++. The VC++ project includes some of the dlls and when I tried double clicking the exe, it is asking for the path of the dll's.
Is it possible to place the generic dll's into a common folder, open the exe file using the batch file and provide the reference path of the dll's??
See this link for information on DLL search order on Windows.
Quick and incomplete summary:
The directory where the executable module for the current process is located.
The current directory.
The Windows system directory.
The Windows directory.
The directories listed in the PATH environment variable.
Note: The LIBPATH environment variable is not used.
EDIT
To address the comment about having the external DLLs copied locally:
After adding the files to your project, right-click one, select Properties. In the General section, change Item Type to Custom Build Tool. Now in the new section Custom Build Tool, change the Command Line to copy that particular file to the output directory.
You can also do all the necessary file copying in the Pre/Post-build steps of the project.
I was wondering if anyone knew how to link a .so dynamic library (or a .a static library for that mater) in Microsoft visual studio. The following steps have not worked for either .a or .so.
I'm playing around with the vs-android plugging to develop in Android NDK using MVS and I'm trying to add a custom library, compiled as a .so, to the project.
1 - I've created a dynamic library (.so) project alongside one of the sample projects (the san-angeles project), in the same solution.
2 - I've set the .so project, let's call it "engine" as a dependency of san-angeles. The engine.so file is generated without any problems, and appears in the {SolutionFolder?}/Android/Debug folder.
3 - I've added engine.so to the linker additional includes of san-angeles and the {SolutionFolder?}/Android/Debug folder (as a full path, something like C:/projects/.../Debug) to the additional linker directories.
But when I compile san-angeles I get the error:
"arm-linux-androideabi-g++.exe: engine.so: No such file or directory"
So I'm guessing I need to do something else to add a .so/.a to a project? Maybe change the name to libengine.so or something like that? A lot of the default includes have the lib prefix, so I don't know if it's something along those lines.
Thank you for the help,
Jaime
For anybody stumbling on this problem:
Add the directory where the .so resides in Linker -> General -> Additional Library Directories. The project you are compiling must be also a Dynamic Library .so for the linker to be available. This appends the -L flag to the commandline
In the Linker -> Command Line append your .so to the Additional Options with the -l flag with quotes, e.g. -l"MyDynamicLibraryWithoutLibPrefixAndExtension". In my case I wanted to link libassimp.so -> -l"assimp"
Ok, so in my case this was solved by:
1 - Naming the generated engine.a as libengine.a
2 - Instead of, from MVS, adding engine.a to Preferences/Linker/Additional Dependencies, I added to Preferences/Linker/Command Line -l"engine"
With this, the project finally managed to find and engine.a
Hope this helps someone else. :)
I've installed the msp430-gcc compiler and associated tools to do some open-source msp430 development at home using Eclipse. I'm developing on a slightly older Macbook Pro running OS X Lion and installed the tools using MacPorts. I'm running Eclipse 3.7.2 with the CDT and GCC Cross Compiler Support plug-ins. I have a simple empty main() written that compiles and links just fine.
The ELF parser lets me view the contents of the ELF binary just fine with the exception of one component; when I try to view the contents of the startup code in crt0.S, it gives me a blank file. When I click on the crt0.S component of the ELF, the filename bar at the bottom of the Eclipse window shows "/opt/local/var/macports/build/_Volumes_work_mports_dports_cross_msp430-gcc/msp430-gcc/work/gcc-4.6.3/gcc/config/msp430/crt0.S". This makes sense because of my MacPorts install of msp430-gcc. crt0.S is archived into /opt/local/lib/gcc/msp430/4.6.3/libcrt0.a on my machine.
What I want to be able to do is tell Eclipse to look elsewhere for the source files for the libraries that are automatically linked when I build with the msp430-gcc toolchain. This would presumably include everything in /opt/local/lib/gcc/msp430/4.6.3/. I started by downloading the source for mspgcc-20120406 (the version in my MacPorts install) and applying the gcc patchfile to an empty directory tree. This created the gcc/config/msp430 directory, including the crt0.S and crt0ivtbl.S files.
What I have had no luck accomplishing is telling Eclipse to look in ~/Developer/mspgcc-20120406/gcc-4.6.3/config/msp430/ instead of the path that's in the already-built libcrt0.a. I tried playing around with the Project Preferences->Paths and Symbols->Source Location window, but didn't have much luck. I searched through this website and on Google and the closest thing I came up with was this question but it doesn't "smell" like the right answer.
I would like to avoid solutions that involve moving the library source into my project. I'd rather have a solution that will work for multiple projects.
All help is greatly appreciated! Thanks in advance.
Try and check if the Eclipse linked resource could help you declare that external directory from within your Eclipse project here.
Linked resources are files and folders that are stored in locations in the file system outside of the project's location. These special resources can be used to add files and folders to your project that for some reason must be stored in a certain place outside of your project. For example, a linked folder can be used to store build output separately from your source files.
I find interesting how you can define that linked resource:
Linked resource target paths can be either defined as absolute paths, or relative to a path variable.
Since you can define it relative to (for instance) your Eclipse project location PROJECT_LOC, you can then setup your resource in a way which won't change between two environments.
My project's directory structure is basically as follows:
root/src
root/assets
root/library
I currently have CMake set up to compile the source, compile the library, and then link them, by calling make from the root directory.
I then have to manually move the executable into the original assets directory to get it to run, since that's where it expects to be (and we want to test with our directory structure in assets as close to what we expect it to be when it's done).
So, is there any way to tell CMake to automatically stick the compiled binary in that directory, as well as copy the assets over? Since we're doing out of source builds, sticking the executable back into the original project source's assets folder seems odd.
In short, two questions: Is there any way to get CMake to copy assets as well as code, and is there any way to have it copy the generated executable to a specific location in the build tree?
Any help would be appreciated --- thank you!
Here's a simple example with a structure like yours:
root/src/main.cpp (only source file)
root/assets (where I want the executable to go)
Here's the cmake file:
PROJECT(HelloCMake)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${HelloCMake_SOURCE_DIR}/assets)
add_executable (HelloCMake src/main.cpp)
When I build against this using Visual Studio I get the output placed in root/assets/debug. I'd have to dig to figure out how to get rid of the extra configuration folder (debug). Not perfect, but hopefully that gets you on the right track.
Edit...Even better:
INSTALL(TARGETS HelloCMake DESTINATION ${HelloCMake_SOURCE_DIR}/assets)