I would like to compile code with such a statement:
c++ -I /usr/boost_1_53_0 boost_test.cpp -o boost \ /usr/lib/boost/libboost_regex.a
but it throws
c++: error: /usr/lib/boost/libboost_regex.a: No such file or directory
I am sure, that libboost_regex.a is existing i above mentioned directory.
How to solve it? I am new to ubuntu and linux.
Looking forward for your tips. Thanks.
The issue is the backslash included in the command line:
c++ -I /usr/boost_1_53_0 boost_test.cpp -o boost \ /usr/lib/boost/libboost_regex.a
^
+-- escaped space character
This backslash escapes the following space character, so that effectively the path name is (using percent encoding for better readability):
%20/usr/lib/boost/libboost_regex.a
To solve it, simply remove the backslash character.
Related
I am facing a strange issue with cd command and cmake.
cd command is not working with the paths which contain '-' minus sign in it. (unless used by tab expansion which is not desireable as path will be provided by ENV variable)
cmake issue
export $SOME_VAR=Some_value_for_this_variable
Now using this in cmake as
set (SOME_OTHER_VAR "$ENV{SOME_VAR}/SUFFIX")
above should give the output as SOME_OTHER_VAR=Some_value_for_this_variable/SUFFIX but instead it is replacing the env variable from starting and giving the output as SOME_OTHER_VAR=SUFFIXalue_for_this_variable means Some_v is replaced from starting with SUFFIX which is not expected.
Please help as i am not getting whats happening.
You're having some sort of character set issue. There are two different minus signs. The hyphen - (ASCII 45, U+002D), and the real minus sign − (U+2212). It's possible that the filename itself got the non-ASCII minus sign, which you can't easily type with your keyboard. The easiest fix would be to rename the file to the normal hyphen. Otherwise, you have to convince CMake to understand your Unicode filename. I have no idea if that's easy or hard.
I think your second problem is similar. The environment variable likely one or more non-printing characters in it, messing up the CMake variables, or at least the display. Try this: from the Linux command prompt, inspect the actual contents of the string.
echo $SOME_VAR | od -t c
For ASCII representation of everything, and/or
echo $SOME_VAR | od -t d1
for the byte contents
I use scons (V1.1.0) for a project that contains a build step that involves the flex tool.
The definition for the flex command in the scons default rules is:
env["LEX"] = env.Detect("flex") or "lex"
env["LEXFLAGS"] = SCons.Util.CLVar("")
env["LEXCOM"] = "$LEX $LEXFLAGS -t $SOURCES > $TARGET"
which I don't want to change.
However, since -t causes #line directives to be created in the output file that refer to the file "<stdout>", this confuses the subsequent gcov processing.
As a solution, I found that -o can be used to override the file name flex produces into the #line directives (it still produces its output on stdout due to the -t option which apparently has precedence).
To achieve that, I added this in the project's SConscript file:
env.AppendUnique(LEXFLAGS = ['-o $TARGET','-c'],delete_existing=1)
I added the -c option (which does nothing) only to show the difference between how it is treated compared to -o.
An according debug print in the SConscript file results in the following (as expected):
repr(env["LEXFLAGS"]) = ['-o $TARGET', '-c']
This results in the following command line, according to the scons log:
flex "-o build/myfile.cpp" -c -t src/myfile.ll > build/myfile.cpp
So the -c option gets into the command line as desired, but the -o option and its filename parameter has double quotes around it, that must have been created by scons when expanding the LEXFLAGS variable.
When I use this definition for LEXFLAGS instead:
env.AppendUnique(LEXFLAGS = ['--outfile=$TARGET','-c'],delete_existing=1)
the resulting command line works as desired:
flex --outfile=build/myfile.cpp -c -t src/myfile.ll > build/myfile.cpp
So one could speculate that the blank in the -o case caused the double quotes to be used, maybe in an attempt to bind the content together into one logical parameter for the command.
So while my immediate problem is solved by using --outfile, my question is still is it possible to rid of the double quotes in the -o case?
Thanks,
Andy
SCons 1.1.0 is extremely old at this point. I'd recommend trying 2.3.0. But your analysis is correct; if an option (a single option, that is) has a space in it, SCons will quote it so it stays a single option. But you don't have a single option; you really have two, '-o' and '$TARGET'. Just break it up like that and it'll work.
I'm trying to get PHP phar command line tool installed on my Debian VM, how here described:
(1) download the php-src, I assume it's in /tmp/php/src
(2) make the dir /tmp/phar
(3) Save this as /tmp/php-src/ext/phar/Makefile.
(4) cd /tmp/php-src/ext/phar
(5) run sudo make
Now after step 5 I get an error:
:/tmp/php-src/ext/phar# make
Makefile:11: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
As I know, there can be two possible causes for this error message:
Tabs in the make file. I've tested the file with od -t c Makefile. The file contains no tabs (\t).
It could be a bug of make v3.81 and need a patch or an upgrade to (yet instable: "Warning: This package is from the experimental distribution.") v3.82. I've downloaded and istalled (dpkg -i make_3.82-1_amd64.deb) it, but the error is still occuring.
What causes the error? How can it be avoided?
Thx
(Answered in a comment: See Question with no answers, but issue solved in the comments (or extended in chat))
#Beta wrote:
The line should begin with a tab, not a bunch of spaces.
The OP wrote:
I've replaced all 8-spaces sequences with tabs and can execute the make script now.
I used:
cat Makefile|sed "s/ /\t/" > Makefile
I am working in MinGW environment (downloaded with their installer on 12/12/2011). I am attempting to compile a resource (.rc) file using Windres. The specific command I use is
Windres -O coff About1.rc -o About1.res
Windres generates at least 100 lines of warning messages reading: "warning: null characters ignored". Following this Windres emits: "Abouty1.rc:1:syntax error".
As a matter of fact, there are no null characters in the About1.rc file. In addtition, the first line of the file is an include statement: #include "dlgresource.h". I played around and eliminated this statement and it turns out that it doesn't matter what I put there, I get the same flurry of messages and the syntax error notification.
To make things more confusing, this same .rc file compiles without any problem using MSFT's rc.exe. The resulting .res file links smoothly with the program .obj file and runs perfectly.
I have no idea what is going on. Any ideas?
Thanks,
Mark Allyn
Your .rc file is probably encoded as UTF-16.
That's what's required in general by Microsoft's [rc.exe], in order to be able to deal with international characters, but GNU [windres.exe] can only deal with ANSI encoding.
One workaround is to convert the file to ANSI on the spot (possibly losing e.g. Russian or Greek characters):
> chcp 1252
Active code page: 1252
> type my.rc | windres --output-format=COFF -o my.res
> _
You probably used VS or a similar tool to generate the file. There are some parts of the character encodings that you cannot see resulting in null characters and etc.
Generate a new .res file with the same content, don't copy/paste the content, type it in yourself.
Try:
windres About1.rc -o About1.o
and then just use the resulting .o file instead of the originally intended .res file.
I've had the same troubles than you today. I know it has passed a lot of time from your question, but I'm writting this on the hope that it can be useful for someone.
First, I obtained an object file .o compiled using Cygwin, writting:
windres -o resource.o resource.rc
By doing that, you dont need to use the .res file, but the .o one, and you can then link this object with all the others, when you compile yout program, using GNU resources:
g++ Header_files CPP_files flags ... -o program.exe recource.o -lm
For instance.
I´m trying to use nmake call MSTest
TEST="%VS90COMNTOOLS%..\IDE\MSTest.exe"
test:
$(TEST) /testcontainer:Test.dll
When i run nmake i got:
$ nmake test
'C:\Program' is not recognized as an internal or external command,
Double quote doesn´t work right
EDIT:
Thanks "Eric Melski".
I created something like:
TEST_="%VS90COMNTOOLS%..\IDE\MSTest.exe"
TEST="$(TEST_)" /nologo /noresults
test:
$(TEST) /testcontainer:Test.dll
Put double quotes around the usage of $(TEST) as well:
TEST="%VS90COMNTOOLS%..\IDE\MSTest.exe"
test:
"$(TEST)" /testcontainer:Test.dll
Works with nmake 7 and 8.
I faced the same problem before. Well, you can escape the white space in CMD with a '\' when you type manually, while the command is auto generated in this case. So my way is to use a another path without white space in it. Make sure you share your way if you find a better one.