While generating kernel image for Xtensa ISS platform
i'm getting compilation error as unrecognized command line option ‘-mlongcalls'
Can any one explain me about the -mlongcalls ? and Why it's unrecognized ?
I'm using Buildroot for generating cross compilation environment.
refer to man gcc
"
**-mlongcalls**
**-mno-longcalls**
When this option is enabled, GCC instructs the assembler to translate direct calls to indirect calls unless it can determine that the target of a direct call is in the range
allowed by the call instruction. This translation typically occurs for calls to functions in other source files. Specifically, the assembler translates a direct "CALL"
instruction into an "L32R" followed by a "CALLX" instruction. The default is -mno-longcalls. This option should be used in programs where the call target can potentially be
out of range. This option is implemented in the assembler, not the compiler, so the assembly code generated by GCC still shows direct call instructions---look at the
disassembled object code to see the actual instructions. Note that the assembler uses an indirect call for every cross-file call, not just those that really are out of range.
"
Related
I am trying to add an external FORTRAN Code to OpenModelica 1.13.0. My function and model definitions are correct and the FORTRAN code normally works. But whenever I add a write(*,*) or read(*,*) method to the code I get the following error as OpenModelica Simulation output:
undefined reference to _gfortran_transfer_real_write##GFORTRAN_1.4
I wonder how can I solve this issue.
Thank you.
This (probably) happens because you are not linking gfortran with the simulation. If the library is shared (so, DLL, dylib), the dependency is usually handled automatically, so you are probably trying to link a static library (.a) or object file (.o, .obj).
In your external function, add an annotation Library="gfortran" or since you probably already have your library in there, Library={"mylib", "gfortran"}.
Also note that OpenModelica 1.13 is getting old and should be upgraded.
For OMShell one can call the setCFlags("-lgfortran") or inside OMEdit add -lgfortran at Simulation Setup > General > C/C++ Compiler Flags. It will solve the issue.
This question follows on from Can you tell me what "crus" means in "LDFLAGS = crus $#"?
Since my error message is "aarch64-poky-linux-ld: cannot find crus: No such file or directory",
where can I find documentation on aarch64-poky-linux-ld?
Best regards,
Next questions: How do I link in needed libraries to a new layer in Yocto?
How do I link librt and libpthread to a new layer in Yocto?
All Linux systems I know of use GNU ld as their linker, part of the binutils package, and it has a complete manual. The aarch64-poky-linux- prefix is a target triplet, used to identify which cross-compilation target this particular ld executable is for.
However, all I think it will tell you is that a string which is not part of an option (starting with - or --) will be treated as an input file. So the message just reports that it is trying to use crus as an input file but it doesn't exist. That's not surprising because as was pointed out on your other question, crus appears to be meant as options to the ar program, not for ld at all. They don't make sense in an LDFLAGS variable. So you will need instead to debug whatever makefile or script decided to try to pass those "options" to aarch64-poky-linux-ld in the first place.
Is there any way in -finstrument-functions option of gcc to get the line number of the current function such as __LINE__ of gcc.
No, you can only access __LINE__ at preprocessing time and __cyg_profile functions are inserted much later. What you could do is get return address (via __builtin_return_address) and symbolize it at runtime (e.g. by calling addr2line). This will of course only work if caller's code was compiled with debuginfo.
EDIT
As pointed out by Tsyvarev below, __builtin_return_address isn't needed as __cyg_profile gets function address as parameter.
I'm trying to compile my first program which uses the NAG library, the following:
program naginfo
use nag_f77_a_chapter
implicit none
write(*,*) 'Calling NAG identification routine'
write(*,*)
call a00aaf
end program naginfo
This is copied from the tutorial and they suggest to compile it with the following statement:
f95 -o naginfo naginfo.f90 -lnag
and they suppose that this -lnag drives the linker to NAG library, but then I find this error:
Fatal Error: Can't open module file ‘nag_f77_a_chapter.mod’ for reading at (1): The directory does not exist
I've tried changing the directory of the NAG files to help the linker find it.
How do I get this to compile and link?
This is just a long explanation of francescalus's comment.
The flag -lnag only adds the library code to the already compiled program when linking all compiled pieces together. It has no effect during compilation and hence no effect on the error message you see.
The compiler must see the information about the NAG library modules. That is usually stored in module files with the .mod extension. Compilers normally only search for these in the current directory or in the system's include directories.
You can instruct the compiler to search in a different directory by using a special compiler flag. It may differ between different compilers, but is typically -I followed by the directory where the library stores its .mod files.
Be advised that the .mod files in the library are only compatible with the same compiler that was used to create them by the library vendor.
I get the following error when I try to install Mininet:
Installing Mininet core
~/mininet ~
cc -DVERSION=\"PYTHONPATH=. bin/mn --version\" mnexec.c -o mnexec
mnexec.c: In function ‘setns’:
mnexec.c:49: error: ‘__NR_setns’ undeclared (first use in this function)
I searched online and found that I could fix the problem by defining the missing system call number appropriately for my 32- or 64-bit kernel.
How do I define the missing system call number for the 32-bit kernel?
I do not know what Mininet is, but I believe your problem may be due to lack of a necessary header file. The error:
mnexec.c: In function ‘setns’: `mnexec.c:49: error: ‘__NR_setns’ undeclared (first use in this function)
Indicates that __NR_setns is not declared in what you are attempting to compile. A little digging shows the possible headers in which it is referenced in Linux. See Linux Cross Reference. A short list of possibilities is:
/usr/include/asm/unistd_32.h
/usr/include/asm/unistd_64.h
/usr/include/bits/syscall.h
/usr/include/valgrind/vki/vki-scnums-x86-linux.h
/usr/include/valgrind/vki/vki-scnums-amd64-linux.h
There are others, but those look the most relevant.