SCons has a ParseFlags() function to turn a compiler command line into build variables. Does this work for MSVC, or does that even make sense?
The man page does say "Parses one or more strings containing typical command-line flags for GCC tool chains", while the user manual says "Historically, it was created to support the ParseConfig method, so it focuses on options used by the GNU Compiler Collection (GCC) for the C and C++ toolchains." It is for GCC.
Related
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
But then, there comes the error: (Make:47 missing endif. Stop).
If I comment out those three lines of code, the error becomes: (<math.h> no such file or directory).
My system is OpenSUSE Leap 15.4; gcc version 7; gnu make version 4.2.1-7.3.2.
I think I have installed all the needed packages. However the errors persist. Any help?
I primarily want to address this part of the question, as the underlying issue has been addressed elsewhere, multiple times:
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
I started to write "Google led you astray", but I think it's more likely that you seriously misunderstood what it led you to. And perhaps you happened to choose poor results.
The error message indicates that you put those lines in your makefile, but they are wholly inappropriate for that. Don't put them there.
The lines are C preprocessor directives that have been stripped of their leading # characters. You would use them by restoring the # characters ...
#ifdef __linux__
#define _finite(v) (__builtin_isfinite(v))
#endif
... and putting the resulting lines into one or more of your C source files. BUT DON'T! Those lines are unnecessary and at best unhelpful.
You do need to #include <math.h> in each C source file that contains a call to isfinite(), because that is the header that provides a declaration of the function. Since C99, functions must be declared before they are called (and it was good practice well before then).
Other than that, with GCC and many other traditional-style Unix C compilers, you need to explicitly include the math library in your link when you need any of the functions it provides. That would involve adding -lm to your makefile, at the end of the gcc command that builds the final executable. This is covered in gcc will not properly include math.h, and many other duplicates on this site.
I want to build statically program with GCC/G++ without shared dependencies. but i don't know how to do that.
With below command in Netbeans IDE i can build with shared dependency, but in some OS can not find this library(i don't want to install on new system)
-Wl,--dynamic-linker=/usr/lib/libexpat.so.1
To statically link a program, you need a static library, which is a library with a filename finished in .a.
Linker, by default, if using default search paths (as you do with /usr/lib), will select the .so library version and will do a dynamic link of it, so if you want to specify that you want some static library, you'll need to specify the full path name of it, instead of using the -l option. So,
gcc -o your_program mod_a.o mod_b.o ... /usr/lib/libexpat.a
is better than
gcc -o your_program mod_a.o mod_b.o ... -lexpat
(the latter will select the file /usr/lib/libexpat.so instead, which should be a link to /usr/lib/libexpat.so.1, which is normally the soname of the library, and is also a symbolic link of /usr/lib/libexpat.so.1.xx.xx)
NOTE
In the examples, I'm trying to call the linker through the compiler, as the default c runtime and libraries are automatically selected by the compiler when calling this way. If you prefer to call directly the linker, the procedure doesn't change, but then you have to add the C runtime module and the standard c library yourself.
NOTE 2
If you want to statically link everything, then you have to use static versions of all the libraries you are going to use (they are normally installed in the same directory as the dynamic ones, so you have to specify the full pathname of all in the command line) To cope with this in a permanent development system, you can make symbolic links to them all from another path and then specify that directory as the search path for your projects that must be statically linked.
If you allways want some library to be statically linked, just erase the .so link (not the .so.X and the .so.X.YY links, they are not tried by the compiler) in /usr/lib, and the .a file will be selected by default by the compiler. Of course, if you want this made for every library, you can erase all the .so links, but you'll end with larger executables (much larger) than the original dynamically linked versions.
i am using scons for different compilers.
vc10 and renesas compiler.
if i compile the program by using env.program(---) am getting the link flags as
"link /nologo /subsystem:console /pdb:project.pdb /OUT:program.exe D:\build1\subdirA\subdirA.lib D:\build1\subdirB\subdirB.lib main.obj"
it is working for VC10 compiler. But for renesas(my microcontroller) compiler, i am getting an error like
"Cannot open file : "/OUT:program.exe""
it will accept " -output=program.abs" command when linking. how can i change that one. can you please tell me
when program is linking /OUT:program.exe is adding by default.
can you please tell me how to change that to "-output=program.abs"
Thank you
What you want to do is called cross-compile: compile a Renesas binary on Windows. Seems like what you have done is loaded the Windows VC10 toolset in SCons (SCons does this automatically unless told not to) and just changed the compiler binary, so SCons is still using the VC10 compiler/linker flags, which dont seem to be compatible. I had to do something similar once with SCons, where I cross-compiled Cavium Octeon in a Linux environment, but luckily for me almost all of the flags were compatible.
I dont know anything about Renesas, but if its compilation flags are more similar to another platform/toolset, then load those instead of Windows, as follows where Im loading the Linux gcc toolset.
env = Environment(tools = ['gcc'])
Look for Construction Environments in the SCons man page for a complete list of supported tools. Keep in mind that by doing this, you will no longer have support for the native platform toolset, Windows VC10 in your case.
When and if you find a similar platform, and you still need to change some compiler/linker flags or options, take a look at changing the related SCons Construction Variables. A few that could be helpful are: CXXFLAGS, LIBSUFFIX, LINKFLAGS, OBJSUFFIX, and PROGSUFFIX. The LINKFLAGS construction variable is actually the answer to your original question.
I did a google search for scons renesas, and came across this link which might also be helpful.
Is there a way to find out what preprocessors are defined in your linux driver/kernel code when building? I could use a text search tool (I actually did), but I inherit a big tree of linux driver/kernel code. It's so big that my text search tool gets an error when I search for a certain preprocessor in the whole code tree.
gcc can dump all defined macros to stdout in preprocessing mode:
gcc -E -dM foo.c
This includes any macros predefined by the compiler, which can be a little annoying. In any case, you should be able to hack up your Makefile to contain a target that dumps this information to files for each compilation unit.
Is it possible to run GDB with a program assembled with as and linked with ld? With gcc adding the flag -g allows for debugging but I get the error No symbol table is loaded. Use the "file" command when I try to add breakpoints to a loaded program.
Thanks!
EDIT Maybe I should make it clear that I'm learning and programming in assembly. All I really want is a stack trace but being able to use GDB would be great.
Resolution Running as -g does the trick.
Thank you to all that answered!!
It is possible. However, you need symbols in order to add symbolic breakpoints, and symbols are provided by debugging info; make sure your assembler and linker are providing those. EDIT With GNU as, use as -g. Or just use gcc -g: if you give it a .s file, it will invoke the assembler and linker as appropriate.
GDB understands debugging info in several formats: stabs, COFF, PE, DWARF, SOM. (Some of these are executable formats with debugging sections, others are debug info formats that can be embedded into executables, such as ELF.) gcc -g usually chooses whatever the platform's default is, gcc -ggdb usually chooses the most expressive (depending on your versions, possibly DWARF-3).
If you have debugging info embedded into or linked to by the executable, gdb will try to load it automatically. If you have it elsewhere, you may need to use file to tell gdb where to find it.
You can still debug without symbolic information. For example, you can issue break *0x89abcdef to insert a breakpoint at that address, if there's any code there.
you could try running as with the --gdwarf-2 or -g options, and make sure ld is not called with --strip-debug, and that your makefile/install process is not stripping the executable.
That's not an error preventing debugging, that's an error setting breakpoints in the way you are trying to do it. Since GDB doesn't have any symbol information, you'll have to set the breakpoints some other way.
If you don't have a symbol table, then you can't set breakpoints symbolically (by function name, line of code, etc). You could still set a breakpoint for a specific address, if you know the address you are trying to stop at.
gdb> b 0x12345678
Of course that's only useful if you know that you want to stop at 0x12345678
What does file say about your executable?