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
Related
while I am building glibc library using yocto project it is giving
error: missing attribute ((constructor)) support??
after adding the coverage flags:
TARGET_CFLAGS += "-fprofile-arcs -ftest-coverage"
TARGET_LDFLAGS += "-lgcov -fprofile-arcs -ftest-coverage"
still, I am getting an error for glibc.
Please find the link of config log file : https://drive.google.com/file/d/14tiQJ8JIFE_tDWt3H9tS8zBBQROcZDNa/view
It is not working even after adding the following line in conf/local.conf :
EXTRA_OECONF = "libc_cv_ctors_header=yes"
Even i tried this
EXTRA_OECONF_append = "libc_cv_ctors_header=yes"
please find the config log file generated during compilation : https://drive.google.com/open?id=1kxTu8pt7h_9ty55OywP9Ilmmp04T61Rr
So, How to resolve this error?
Log file error Point
poky-linux/gcc/i586-poky-linux/8.2.0/ld: /tmp/ccxetEc1.o: in function `_GLOBAL__sub_D_00100_1__start':
conftest.c:(.text.exit+0x40): undefined reference to `__gcov_exit'<br>
collect2: error: ld returned 1 exit status<br>
configure:5682: $? = 1<br>
configure:5702: error: missing __attribute__ ((constructor)) support??
You are trying to build glibc with -fprofile-arcs -ftest-coverage in CFLAGS. That will not work. The errors you see are a result of these incorrect compiler flags.
A profiling glibc requires fairly substantial changes throughout the library and needs to be created by building with --enable-profile (which is not the default).
I had this error while I tried to enable coverage on a C project using a C++ test harness (CppUTest). Build system was handled by CMake.
Compilers and gcov were aligned on the same version (gcc --version, g++ --version and gcov --version gave the same version) but it seems that my build system was generated with a gcc 5 (resulting to an additional included directory by the linker: usr/lib/gcc/x86_64-linux-gnu/5). I clean the build tree and generated it again thanks to CMake which fixed the error.
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.
I'm attempting to install the following Haskell package on Windows using Cygwin: HaskellCuda
You can install the package using "cabal install cuda".
Here is the output I get (you may have to "cuda install c2hs" first):
$ cabal install
Configuring cuda-0.4.0.2...
checking for gcc... C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
Resolving dependencies...
cabal.exe: Error: some packages failed to install:
cuda-0.4.0.2 failed during the configure step. The exception was:
ExitFailure 77
The relevant part from the log file is:
configure:1758: checking for gcc
configure:1785: result: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe
configure:2022: checking for C compiler version
configure:2029: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe --version >&5
configure: line 2030: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2035: $? = 127
configure:2042: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe -v >&5
configure: line 2043: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2045: $? = 127
configure:2052: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe -V >&5
configure: line 2053: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2055: $? = 127
configure:2078: checking for C compiler default output file name
configure:2105: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe -fno-stack-protector conftest.c >&5
configure: line 2106: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2108: $? = 127
configure:2146: result:
configure: failed program was: [source elided]
If I go to Cygwin and type
gcc --version
I get something reasonable. The problem appears to be more with the path I guess, but I'm not sure what/how to fix it. I should also note that using "cabal install cuda-0.2.2", an older version of this package, I get past this step (but get a different error later).
To replicate, make sure you install the Haskell Platform in a path without spaces, otherwise you will probably get a different error. That's the only thing I've figured out so far.
Any help with this would be GREATLY appreciated, I've spent about a week so far and haven't gotten anywhere.
EDIT:
$PATH = C:\Haskell\2011.4.0.0\mingw\bin;
C:\Haskell\2011.4.0.0\lib\extralibs\bin;
C:\Haskell\2011.4.0.0\bin;
C:\CUDA\v4.0\bin\;
C:\cygwin\bin\;
...
I managed to get it to install, but it isn't pretty and I don't really understand why it won't work out of the "autoconf" box.
For starters, rather than installing with "cabal install" (using a local copy), I used the sequence
>runhaskell Setup.hs configure
>runhaskell Setup.hs build
>runhaskell Setup.hs install
The main reason for this is because it is simple to change the $CC variable in the configure script using the argument in Setup.hs. I suspected the $CC was the variable giving me the problem. I changed:
[("CC", ccProg)
to
[("CC", "/cygdrive/c/cygwin/bin/gcc.exe")
in Setup.hs, which is the gcc that comes with Cygwin. My initial suspicion was that autoconf didn't like the Windows-style path to gcc, which it was using based on the log file above. I also discovered though that of the multiple copies of gcc on my computer (one in Haskell/mingw, one in a separate installation of mingw, and whichever version $PATH was pointing to, ONLY the cygwin gcc was able to successfully compile the test file that checked for . Using the cygwin gcc, I could run
gcc hello.c
on any file that included (WITHOUT an external include directive), whereas with any other copy of gcc, even something like
gcc -I/cygdrive/c/..../include hello.c
was not able to find . No idea why.
Just changing the $CC to the Cygwin gcc fixed almost all of the errors. The next errors occurred when "checking for library containing cudaRuntimeGetVersion/cuGetDriverVersion".
The file configure was trying to compile was
#define PACKAGE_NAME "Haskell CUDA bindings"
#define PACKAGE_TARNAME "cuda"
#define PACKAGE_VERSION "0.4.0.0"
#define PACKAGE_STRING "Haskell CUDA bindings 0.4.0.0"
#define PACKAGE_BUGREPORT "tmcdonell#cse.unsw.edu.au"
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define HAVE_CUDA_H 1
#define HAVE_CUDA_RUNTIME_API_H 1
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char cudaRuntimeGetVersion ();
int main ()
{
return cudaRuntimeGetVersion ();
;
return 0;
}
using the command:
/cygdrive/c/cygwin/bin/gcc.exe -o conftest.exe -fno-stack-protector
-I/cygdrive/c/CUDA/v4.0/include -L/cygdrive/c/CUDA/v4.0/lib conftest.c -lcudart
The error (from the log file) is
/cygdrive/c/Users/crockeea/AppData/Local/Temp/ccKMQJiq.o:conftest.c:(.text+0xc):
undefined reference to `_cudaRuntimeGetVersion'
I'm a little rusty on my C, but it seems like they aren't include the appropriate header file here. That probably isn't right because the same file works on Unix based systems when running configure, but it's my best guess. Also, editing configure to make this file include cuda.h just results in a different error about multiple definitions of cudaRuntimeGetVersion. So my hack was to comment out the lines in the configure file with references to cudaRuntimeGetVersion/cuGetDriverVersion. I put C-comments into the C files that the configure file was going to compile (it is easy enough to find the source code for these in the configure file based on line numbers from the log file). I don't know the consequences of modifying the configure file in this way.
This allowed me to get past the 'build' phase. More comments if I run into any other issues.
I was trying to compile libSDL-1.2.14 for my mips platform.
But it was not successful.
These were the steps that I tried out :
export PATH=/opt/mips-4.3/bin:$PATH
Went inside the libSDL-1.2.14 source folder.
Gave a "./configure --prefix=/usr/local/SDL_Lib --host=mips-linux-gnu"
Executed the "make" command
This was the error received :
cc1: warning: include location
"/usr/include" is unsafe for
cross-compilation
./src/audio/dma/SDL_dmaaudio.c: In
function 'DMA_WaitAudio':
./src/audio/dma/SDL_dmaaudio.c:167:
error: can't find a register in class
'COP3_REGS' while reloading 'asm'
./src/audio/dma/SDL_dmaaudio.c:167:
error: 'asm' operand has impossible
constraints make: *
[build/SDL_dmaaudio.lo] Error 1
But then i reconfigured the make file by giving the following commands :
make clean
./configure --prefix=/usr/local/SDL_Lib --host=mips-linux-gnu CPPFLAGS=-I/opt/mips-4.3/mips-linux-gnu/libc/usr/include/
make
NOTE : /opt/mips-4.3/mips-linux-gnu/libc/usr/include/ - This is the path where you can locate the select.h file for the mips Platform.
It contains the definitions of the macros FD_ZERO and FD_SET.
Still I am getting the same error.
cc1: warning: include location
"/usr/include" is unsafe for
cross-compilation
./src/audio/dma/SDL_dmaaudio.c: In
function 'DMA_WaitAudio':
./src/audio/dma/SDL_dmaaudio.c:167:
error: can't find a register in class
'COP3_REGS' while reloading 'asm'
./src/audio/dma/SDL_dmaaudio.c:167:
error: 'asm' operand has impossible
constraints make: *
[build/SDL_dmaaudio.lo] Error 1
Please help me with some valuable pointers.
Thanks,
Sen
First, don't set the path to the cross-compiler as the first part of your PATH, set it as last:
export PATH=$PATH:<path to cross-compiler>
It's safer this way. Second, run ./configure --help to get all the options. What that error message would say if it was smarter is the following:
You're trying to cross-compile since you're setting the --host flag
But you're not changing any of the other options for where to find includes and libs for the target environment
I'm going to use /usr/include by default
But that's for the host system which will not work when cross-compiling
Check what other configure options you need to set to tell the configure script where to find the .h files (includes) and the libraries for your target. These usually come with the cross-compiler that you download. Also, you should probably set the CROSS_COMPILE environment variable to the cross-compiler prefix before running configure. The prefix is the part before gcc in a cross-compiler, assuming you're using GCC as your cross-compiler.