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.
Related
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.
I'm to continue maintenance on several programs called "Legacy Projects". I have a separate Windows XP system for that.
Most of these are VB6 programs. I have one to which I was forced to make changes. Only now it refuses to make the new executable, giving the above error message :
LINK : fatal error LNK1104: cannot open file "C:\Documents And Settings\Me\My Documents\VB6 Projects\Some Directory Path Name\MyProjectDirectory\MyProjectExecutable.exe
I've opened an older version of the project and it compiled and created the executable fine.
Out of frustration, I created a brand new project, moved the source files ( forms, modules and class modules ) over to it, and tried again. It failed. Again. Still.
Why.
I'll take a guess on insufficient information.
PRB: LINK Fatal Error LNK1104 Cannot Open File
Q166470
SYMPTOMS
When compiling an ActiveX component with binary compatibility set to the same file the compile is attempting to overwrite, the following error occurs:
LINK fatal error LNK1104 cannot open file.
RESOLUTION
To work around this problem, copy the ActiveX executable or DLL to a separate directory. Set binary compatibility to the copied file, and
compile to the original directory. This procedure is described in
Microsoft Visual Basic Books Online.
More generally you could have looked up the VC++ linker reference, which all MS languages use.
Linker Tools Error LNK1104 cannot open file "filename"
The tool could not open the given file.
Tips
One of the following may be a cause:
There was not enough disk space.
The file does not exist.
The filename or its path was incorrectly specified.
The specified drive is invalid.
The file does not have the appropriate permissions.
The path for filename expands to more than 260 characters.
If the given file is named LNKn, which is a filename generated by the
linker for a temporary file, then the directory specified in the TMP
environment variable may not exist, or more than one directory is
specified for the TMP environment variable. (Only one directory path
should be specified for the TMP environment variable.)
If the error occurs on the executable filename, an earlier version of
the executable may still be running. You will need to terminate the
executable before linking it. In Windows NT or Windows 95 you can use
the utility PVIEW to look for and kill instances of the application.
PVIEW.EXE is shipped with Visual C++.
If the error message occurs for a library name, and you recently
ported the .MAK file from a previous Microsoft Visual C++ development
system, the library may no longer be valid. Ensure that the library
still exists in this circumstance.
I have an application that depends on some .dll files.
I know if I just make them in the same folder as the .exe file, it would work, but I don't want to leave 30 .dll files with my .exe file. Is there a way I can put them in a folder with my .exe file ?
Or even better, is it possible to compile them and link them with the .exe file to have a standalone file? And no I don't have the static version of these dynamic libraries.
(p.s. the application is written with c, compiled with gcc, mingw win64, and the .dll are from gtk3 libs)
Thank you for reading my question
You have a number of options.
A) get hold of the library files, .lib on windows and statically link with these libraries.
B) It is a bit of a hack but you can attach resources into a Windows executable. This is usually used for strings, icons, that sort of thing, but you could even attach in a binary file. But if you do this you would probably need to generate the dll binaries at program startup and save to eg same folder as your executable. So no point in doing this really, simply distribute in the same folder as your exe. What is the problem doing that? (lookup LoadResource, FindResource, MAKEINTRESOURCE, etc)
C) If you don't want to put the dlls is the same path as your exe you will need to store them in a folder in your system's path env variable. Eg you could copy them to C:\Windows - but due to security that will be harder. You could create your own dll_path and add this path to the env variable as part of the installation of your program.
D) One other variation on C) is that you copy to for example a subdirectory of you exe location, called eg dll_files. Then you use a startup script to launch your program like this:
#echo off
set PATH=%PATH%;<path to dll files>
myprogram.exe
Let's make is simple
download winrar from www.rarlab.com/download.htm A) create standalone winrar executable pack your file in archive and execute your main program.
no idea how to create standalone installer guide for you
http://www.groovypost.com/howto/howto/how-to-make-your-own-offline-installers-using-winrar/
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.
How does one properly use file paths in source code (relative to the project root) when building with cmake?
Details:
I have a cmake project with basically this layout:
project
|-src/
| |-main.c
| |-CMakeLists.c
|-dat/
| |-foo.txt
|-build/
main.c basically contains a main function that tries to open a file, specified relative to the project's root directory, i.e., dat/foo.txt. When building with cmake, the binaries are located in project/build/src, which is also the working directory when running the program. dat/foo.txt is interpreted as project/build/src/dat/foo.txt which obviously is not available. One could replace the path in the source file with ../../dat/foo.txt, which however is not at all a clean and nice solution.
This stackoverflow post states that there is no easy way for setting the working directory of code executed by cmake (furthermore, the answer refers to a solution for Visual Studio, which I am not using).
What is the best practice for this problem?