I have an InnoSetup script I have been using for years, and suddenly it stopped working, specifically on this line in the [Setup] section:
WizardImageFile={src}\..\..\images\InstallBanner.bmp
The error reported is:
Compiler Error!
Line 47: Could not read "C:\projects\xxxx\installer\{src}\..\..\images\installbanner.bmp".
Error: The system cannot find the path specified.
Two potential problems I noticed, {src} is still in the file path reported, and the file name is all lowercase. Except for these two issues, the file name is correct, and the file exists.
Am I using the {src} constant incorrectly and this has previously worked by coincidence, or is this a bug that was introduced with an update?
Currently running 6.0.2. I know 6.0.4 is released, but cannot currently install it, and didn't notice an issue like this mentioned in the revision history.
You cannot use constants in WizardImageFile. It makes no sense. The constants are evaluated on runtime. While WizardImageFile is read on compile time. Also {src} refers to the path, from where an installation was started. How would it evaluate, when you are only building the installer?
If it ever worked, you must have subfolder with literal name {src} somewhere on the path, where you were compiling the installer.
As #MartinPrikryl said, {src} and other constants cannot be used as they are evaluated at runtime. Definitions may be used, and the {#SourcePath} definition works as a starting path relative to the script location
WizardImageFile={#SourcePath}\..\..\images\InstallBanner.bmp
Related
I'm revisiting an old Chrome App project and have all the SDKs (Pepper 49) installed and Python etc.
My previous project folder is accepted by Chrome in Dev mode and runs.
However, I now need to add to the project and the build/make process is showing the error below:
The directory tree I used last has changed, which is why I've highlighted the full directory my project is in.
Is this as simple as Make.exe not supporting string gaps in the directory names? The error implies this could be the case.
That's a quoting problem. The spaces aren't quoted on the command line so they are being seen as significant by the shell and STAMPDIR is being set to only V:/Code while Repositories/BCS and Chrome/BCS are being seen as additional command line arguments to make and make assumes they are targets to build (and can't do so).
You'll need to quote the argument in the makefile so that it gets put on the command line correctly.
I am trying to debug an application that is cross-compiled on a Windows host for a Linux target.
The problem:
Because the initial compilation is in windows the stored source file paths in the binary is of the form C:\Users\foo\project\.... On the Linux target I have put the source files under \home\foo\project\.... By default gdb does not find the source file because of the different path.
What I have tried so far:
Use "directory" command in gdb to give an exact path for the .c source file in the target Linux system where the app is being debugged. This works but unfortunately there are literally hundreds of files so this solution is unrealistic.
Use the set substitute-path C:\\Users\\foo\\project /home/foo/project command to have gdb substitute all prefixes. Note that the \\ seems necessary such that show substitute-path registers the right string. This unfortunately does not work. My guess is that the substitute-path command does not handle ms-dos style paths.
Tried separating the debug info out into a separate .debug file (see How to generate gcc debug symbol outside the build target?) and then using debugedit to change the paths with the command debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug. Unfortunately this does not work either. debugedit seems to work fine if the existing path is all UNIX/Linux like but doesn't seem to work with ms-dos style paths.
I have looked around stackoverflow and while there are similar topics I can't find anything that will help me. Would really appreciate any suggestions/help. I realize that cross compiling from Windows is a very roundabout way but can't avoid that for the moment.
Thanks
Although it's rather old question, I did encountered the same problem. I managed to resolve it but using sed on binary executable... (yeah, a 'bit' hack-ish, but did not found another way). With sed I've managed to replace symbols paths right inside the executable, the trick is that new path's length should be the same as the old one.
sed -i "s#C:/srcpath#/srcpath/.#g" ./executable
Be sure to make new path the same length, otherwise the executable will brake.
I also have this same problem. Your option 1 isn't as bad as you think because you can script creating all the 'directory' commands with something like this python code:
def get_directory_paths():
return_array = list()
unix_path = os.path.join('my','unix','path')
for root, dirs, files in os.walk(unix_path):
for dir in dirs:
full_unix_path = os.path.join(root,dir)
escaped_unix_path = re.sub("\s", "\\\\ ", full_unix_path)
return_array.insert(0, "directory " + escaped_unix_path)
return '\n'.join(return_array)
The downside is that if you have two source files with the same name in different directories, I don't think gcc can pick the right one. That worries me, but in my particular situation, I think I'm safe.
For option 2 (which I suspect would fix the aliasing condition from #1), I think the problem is that the substitutions are not ending with a "file separator" according to the linux so they aren't applied:
To avoid unexpected substitution results, a rule is applied only if the from part of the directory name ends at a directory separator. For instance, a rule substituting /usr/source into /mnt/cross will be applied to /usr/source/foo-1.0 but not to /usr/sourceware/foo-2.0. And because the substitution is applied only at the beginning of the directory name, this rule will not be applied to /root/usr/source/baz.c either." (from https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html#index-set-substitute_002dpath )
I haven't tried anything like your #3 and I also considered something like #dragn suggestion, but in my situation the paths are not even close to the same length, so that will be an issue.
I think I'm stuck with #1 and a script, but if anyone has other suggestions, I'm interested options :-)
I am new to F#. I get the following error when I attempt to build my F# project in Monodevelop:
/home/greenrd/git/hello/hello: Error FS0229: Error opening binary file
'/usr/lib/mono/4.0/../../../../../usr/lib/mono/gac/kde-dotnet/4.1.0.0_194a23ba31c08164/kde-dotnet.dll':
Could not find a part of the path
"usr/lib/mono/gac/kde-dotnet/4.1.0.0_194a23ba31c08164/kde-dotnet.dll".
(FS0229) (hello)
I don't think this is due to the 260 character file path limit in .NET, for the simple reason that the file path is only 102 characters. What could be the problem? file says:
/usr/lib/mono/4.0/../../../../../usr/lib/mono/gac/kde-dotnet/4.1.0.0__194a23ba31c08164/kde-dotnet.dll:
PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS
Windows
I don't even know where this filename comes from, I didn't enter such a strange filename anywhere. All I did was add the KDE C# bindings as a reference to the project.
This looks like a bug in the compiler when there are more .. than required - it looks like in this case the compiler drops the leading slash.
Changing the reference to
/usr/lib/mono/gac/kde-dotnet/4.1.0.0__194a23ba31c08164/kde-dotnet.dll
works just fine.
I am trying to chase this error up. Hopefully I will have a compiler patch today or tomorrow.
So after chasing a whole stack of functions in the compiler, it turns out this is actually a mono bug. This simplest way to reproduce it is
new FileStream("/../bin/bash",FileMode.Open,FileAccess.Read,FileShare.ReadWrite);;
which should work, but doesn't.
Reported to mono: https://bugzilla.xamarin.com/show_bug.cgi?id=17083
EDIT: This is apparently fixed in the latest mono - https://bugzilla.xamarin.com/show_bug.cgi?id=17083
I am using F# in Visual Studio 2012 and this may seem like a dumb question but I cannot figure out how to specify include directories, specifically for binaries. I see how to do it for F# interactive using the #I directive and it works there, but the #I option is not available in the non-interactive form. The compiler error message says to use the -I compiler option. I have looked under Project Properties, where the only subsections visible are Application, Build, Build Events, Debug, and Reference Paths none of which provides any obivous way to specify an include directory path. The help system isnt much help as it seems to reference sections that are unavailable.
Well i still have the problem with VS12 but at least i have a workaround, by calling the compiler from the command line. You have to use the -r option to specify the location of the dll:
fsc -r:<complete path to dll> <fname>
However when i try the corresponding step in VS (by trying to set one of the Reference Paths) it says there are no items found in the DLL folder. So perhaps someone familiar with CS can help out
Error 2 error LNK1104: cannot open file 'OgreMain_d.lib' C:\Users\Owner\Documents\Code\C++\Test\ogrevcpp\ogrevcpp\LINK ogrevcpp
This is the error I get when trying to build an Ogre3D application (with steps followed from here).
I've followed everything to the T, yet I still get the error. It honestly shouldn't be happening. I've also followed everything from here.
Edit
What's happening is there are two different files, one is meant for release, the other is meant for debug. I need the one for debug mode to compile properly (which is OgreMain_d.lib).
Update
I figured out what the problem was - I was using the incorrect binaries; there was a few releases which were meant for Visual C++, and one which was meant for MinGW, along with a few other compilers. My apologies.
You need to check your library paths to make sure that the path where OgreMain_d.lib lives is part of the library path.
I guess the library for Debug mode is not present in the lib folder. Try putting two different libraries folder for each Assembly mode in Visual Studio. Go to ProjectProperties -> Configuration Properties -> Linker -> Additional Library Directories on Right hand. Make sure to check the Configuration Dropdown on the top.