I am getting these errors when i compile sim_routing.cc program by this command:
../../bin/cxx sim_routing.cc
g++ -Wall -o sim_routing sim_routing.cxx
The following errors are shown:
../../common/priority_q.h : In member function 'bool guardedQueue<ITEM>::Validate(Const char*);
error : there are no argument to 'strcat' that depend on template parameter so a declaration of 'strcat' must be avaible.
error : <if you use -fpermissive g++ will accept your code but allowing use of undeclared name is deprecated>
When i tried to change the commom/priority_q.h file, it shows it is read only file, so changes cannot be made.
How can these errors be corrected?
Not sure about this, but you could possibly try to include
#include <cstring>
before you include that priority_q.h file in your code. That should bring strcat's declaration in scope before that template is processed.
Related
I have to compile a c and c++ library with rpc for accessing meeasurement devices, that uses the standrd VXI11, see vxi11-library.
OS: opensuse tumbleweed
Compiler: gcc 12.1.0
After adding the include path -I/usr/include/ntirpc the program at least find the include path (rpc/rpc.h, obviously has been shifted around).
I had to change the name of some functions, but one error remained:
g++ -g -I/usr/include/ntirpc -c vxi11_cmd.cc -o vxi11_cmd.o
In file included from /usr/include/ntirpc/rpc/rpc.h:47,
from vxi11_user.h:31,
from vxi11_cmd.cc:25:
/usr/include/ntirpc/rpc/xdr.h:136:18: error: declaration of ‘vio_type xdr_vio::vio_type’ changes meaning of ‘vio_type’ [-fpermissive]
136 | vio_type vio_type; /* type of buffer */
/usr/include/ntirpc/rpc/xdr.h:126:3: note: ‘vio_type’ declared here as ‘typedef enum vio_type vio_type’
126 | } vio_type;
Anybode can help me, fixing thies error?
Thanks,
Johannes
I'm using the latest LDC2 beta, and when running the compiler with -I (Look for imports also in ) it fails with unresolved externals. These are my commands.
$ ldc2 "source\setup.d" -I "source" -J "build\vars" -of "build\bin\setup.exe" -m32 -g
setup.obj : error LNK2019: unresolved external symbol __D6common17createErrorDialogFxC9ExceptionZv referenced in function __Dmain
setup.obj : error LNK2019: unresolved external symbol __D6common14getConsoleArgsFxPuZAAya referenced in function __D5setup20getAvailableBrowsersFZ14__foreachbody1MFKC3std7windows8registry3KeyZi
setup.obj : error LNK2001: unresolved external symbol __D6common12__ModuleInfoZ
build\bin\setup.exe : fatal error LNK1120: 3 unresolved externals
Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\link.exe failed with status: 1120
But this next one works fine when I explicitly tell the compiler that setup.d depends on common.d.
$ ldc2 "source\setup.d" "source\common.d" -J "build\vars" -of "build\bin\setup.exe" -m32 -g
I'm using LDC2 version 1.12.0-beta2, on DMD v2.082.0, on Windows with VS Build Tools 2017.
Any solutions or corrections appreciated.
Note: These compiler commands will be generated by other code, so using explicit filenames isn't feasible.
-I tells it where to find source code to import. The assumption is that the actual object code will be found in a pre-compiled library (or separate .obj files) somewhere that you pass to the linker.
If you want it to include the files in the build, using one of the newest ldc builds (as of the last couple months), it also has -i in addition to -I you can pass. -I tells it where to find the import files. -i tells it to add them to the build, instead of just treating them as an external library header.
So that's your three options:
compile the library separately, and add the resulting lib file to the link step
pass the source files all together on the command line (if it is generated by other code, just change that code to walk the directory lol)
get one of the latest compiler versions and add -i to the build command.
I have downloaded Rocket-chip from GIT, installed RISC-V tools and Generated the verilog files for Rocket core. Now I want to run the assembly tests that are given but I dont have VCS instead I have Questasim. I modified the Makefile to use Questasim but the two C++ files that needs to be compiled SimDTM.cc and jtag_vpi.c are giving error.
In Questa we cant compile C files along with verilog files instead we need to compile this separately and generate *.so file and link with -pli while simulating.
Here when I'm compiling jtag_vpi.c I'm getting and error saying invalid conversion from 'void*' to 'PLI_INT32. I'm compiling it with the below command and the error I'm getting is also pasted below.
g++ jtag_vpi.c -I $RISCV/include -I $MTI_HOME/questasim/include -std=c++11 -W -shared -Bsymblic -fPIC
.
.
riscv/rocket-chip/csrc/jtag_vpi.c:398:2: error: invalid conversion from ‘void*’ to ‘PLI_INT32 (*)(t_cb_data*) {aka int (*)(t_cb_data*)}’ [-fpermissive]
Line 398:2 is just an end of a function and the error is shown at the end of each such function.
Any help will be useful.
Thanks in advance.
I am porting an application from Solaris to Linux
The object files which are linked do not have a main() defined. But compilation and linking is done properly in Solaris and executable is generated. In Linux I get this error
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
My problem is, I cannot include new .c/.o files since its a huge application and has been running for years. How can I get rid of this error?
Code extractes of makefile:
RPCAPPN = api
LINK = cc
$(RPCAPPN)_server: $(RPCAPIOBJ)
$(LINK) -g $(RPCAPIOBJ) -o $(RPCAPPN)_server $(IDALIBS) $(LIBS) $(ORALIBS) $(COMMONLIB) $(LIBAPI) $(CCLIB) $(THREADLIB) $(DBSERVERLIB) $(ENCLIB)
Try adding -nostartfiles to your linker options, i.e.
$(LINK) -nostartfiles -g ...
From the gcc documentation:
-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
This causes crt1.o not to be linked (it's normally linked by default) - normally only used when you implement your own _start code.
-shared link option must be used when you compile a .so
The issue for me was, I by mistake put int main() in a namespace. Make sure don't do that otherwise you will get this annoying link error.
Hope this helps anyone :)
I had similar result when trying to build a new test project with boost, and it turned out that I was missing one declaration :
#define BOOST_TEST_MODULE <yourtestName>
I had this same problem when creating my c project, and I forgot to save my main.c file, so there was no main function.
I had a similar result when compiling a Fortran program that had C++ components linked in. In my case, CMake failed to detect that Fortran should be used for the final linking. The messages returned by make then ended with
[100%] Linking CXX executable myprogram
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[3]: *** [myprogram] Error 1
make[2]: *** [CMakeFiles/myprogram.dir/all] Error 2
make[1]: *** [CMakeFiles/myprogram.dir/rule] Error 2
make: *** [myprogram] Error 2
The solution was to add
set_target_properties(myprogram PROPERTIES LINKER_LANGUAGE Fortran)
to the CMakeLists.txt, so that make prints out:
[100%] Linking Fortran executable myprogram
[100%] Built target myprogram
I had the same issue with a large CMake project, after I moved some functions from one code file to another. I deleted the build folder, recreated it and rebuilt. Then it worked.
Generally, with suddenly appearing linker errors, try completely deleting your build folder and rebuilding first. That can save you the headaches from trying to hunt down an error that actually simply shouldn't be there: There might be CMake cache variables floating around that have the wrong values, or something was renamed and not deleted, ...
I had the same issue as to OP but on on FreeBSD 13.1.
What solved the issue was simply adding:
int main()
{
}
Since the .cpp file was only an object file containing definitions and declarations using:
extern "C"
{
<all definitions and declarations code goes here>
}
Every time I tried compiling this, the compiler kept throwing the same error as to OP.
So all I did was add an empty main() function all the way at the bottom and code compiled with no errors.
In my project, I include pfring.h, but compile error: some functions in net/if.h and linux/if.h are redefinition. I found that the pfring.h include linux/if.h
So, I test a program, my test code:
#include <linux/if.h>
#include <net/if.h>
int main(void) {
return 0;
}
It expected compile error.
So, what's wrong with linux/if.h and net/if.h ?
Can not I include them at once?
error message:
In file included from test.c:1:0:
/usr/include/linux/if.h:178:19: error: field 'ifru_addr' has incomplete type
/usr/include/linux/if.h:179:19: error: field 'ifru_dstaddr' has incomplete type
/usr/include/linux/if.h:180:19: error: field 'ifru_broadaddr' has incomplete type
/usr/include/linux/if.h:181:19: error: field 'ifru_netmask' has incomplete type
/usr/include/linux/if.h:182:20: error: field 'ifru_hwaddr' has incomplete type
In file included from test.c:2:0:
/usr/include/net/if.h:45:5: error: expected identifier before numeric constant
/usr/include/net/if.h:112:8: error: redefinition of 'struct ifmap'
/usr/include/linux/if.h:136:8: note: originally defined here
/usr/include/net/if.h:127:8: error: redefinition of 'struct ifreq'
/usr/include/linux/if.h:170:8: note: originally defined here
/usr/include/net/if.h:177:8: error: redefinition of 'struct ifconf'
/usr/include/linux/if.h:219:8: note: originally defined here
For me (on Ubuntu 12.04 x64) the following include solved the problem:
#include <sys/socket.h> // <-- This one
#include <linux/if.h>
#include <linux/if_tun.h>
This problem has been resolved, add the compile flag -DHAVE_PCAP is fix. ;-)
At first let us talk about the source: The header files are from different Packages as you can see asking dpkg.
$ dpkg -S /usr/include/linux/if.h
linux-libc-dev:i386: /usr/include/linux/if.h
$ dpkg -S /usr/include/net/if.h
libc6-dev:i386: /usr/include/net/if.h
linux-libc-dev is part of linux kernel packages while libc6-dev is part of the libc6 (Standard C library in version 6).
It seams like they are interchangeable so you should only use one (not 100% sure about this). If you pick linux/if.h, you may depend on Kernel versions with your compiled binary.
All new Library versions I have in mind stick with net/if.h instead of the linux one - so you should do the same.
If you are using one of the interface state flags (eg: IFF_UP, etc.), you need one more header than mentioned in other posts.
#include <sys/types.h> // <==
#include <sys/socket.h>
#include <linux/if.h>