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.
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
Here's what I did.
In path ./linux-5.7
mkdir hello
cd hello
vim hello.c
#include <linux/kernel.h>
asmlinkage long sys_hello(void) {
printk ("\n\nHello Kernel\n\n");
return 0;
}
vim Makefile
obj-y := hello.o
vim arch/x86/entry/syscalls/syscall_64.tbl
439 common hello sys_hello
vim include/linux/syscalls.h
asmlinkage long sys_hello(void);
...
...
Compile the kernel
make -j4
Error ...
ld: arch/x86/entry/syscall_64.o:(.rodata+0xdb8): undefined reference to `__x64_sys_hello'
make: *** [Makefile:1113: vmlinux] Error 1
What's wrong here...
...
...
...
I experienced similar problem, but the solution from Joseph's comment didn't work out for me. So, this answer is for those who tried Joseph's one but had not made progress.
Here's steps that I took based on Kernel document
After you put __x64_ in front of the entry point, if you got an error such as
ld: arch/x86/entry/syscall_64.o:(.rodata+0xdc8): undefined reference to `__x64___x64_sys_my_syscall'
ld: arch/x86/entry/syscall_x32.o:(.rodata+0xdc8): undefined reference to `__x64___x64_sys_my_syscall'
make: *** [Makefile:1179: vmlinux] Error 1
then rather then put __x64_ in front of entry point of your syscall, put syscall into both of your arch/x86/entry/syscalls/syscall_64.tbl and arch/x86/entry/syscalls/syscall_32.tbl without any prefix such as
- At the `arch/x86/entry/syscalls/syscall_64.tbl`,
441 common my_syscall sys_my_syscall
- At the arch/x86/entry/syscalls/syscall_32.tbl`
441 i386 my_syscall sys_my_syscall
After this, if you still have same problem, then add your syscall into general syscall table: syscall list that shared among several architectures.
Put following in include/uapi/asm-generic/unistd.h:
#define __NR_my_syscall 441
__SYSCALL(__NR_my_syscall, sys_my_syscall)
Note that the kernel version I used is WSL2-Linux-Kernel-linux-msft-wsl-5.10.60.1 and it's built in x64 architechture.
I'm quite novice in OS and linux kernel, so this is just what worked for me and I don't know the exact mechanisim of it; sorry for no mechanisim explanation.
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 am using Ubuntu 14.04LTS. I have installed the SDL2 libraries both by compiling from source (method1 https://askubuntu.com/questions/344512/what-is-the-general-procedure-to-install-development-libraries-in-ubuntu) and using sudo apt-get install libsdl2-dev.
As I understand, the former installed the libraries and headers in /usr/local/(lib and include), while the latter installs them system wide in /usr/(lib and include).
When I tried to compile a simple code to test the functionality:
#include <SDL.h>
#include <stdio.h>
int main(int argc, char* argv[]) {SDL_Window *window;
// Declare a pointer
SDL_Init(SDL_INIT_VIDEO); // Initialize SDL2
// Create an application window with the following settings:
window = SDL_CreateWindow(
"An SDL2 window", // window title
SDL_WINDOWPOS_UNDEFINED, // initial x position
SDL_WINDOWPOS_UNDEFINED, // initial y position
640, // width, in pixels
480, // height, in pixels
SDL_WINDOW_OPENGL // flags - see below
);
// Check that the window was successfully created
if (window == NULL) {
// In the case that the window could not be made...
printf("Could not create window: %s\n", SDL_GetError());
return 1;
}
// The window is open: could enter program loop here (see SDL_PollEvent())
SDL_Delay(3000); // Pause execution for 3000 milliseconds, for example
// Close and destroy the window
SDL_DestroyWindow(window);
// Clean up
SDL_Quit();
return 0;
using: g++ sdl_test.cpp -o sdlout
the compiler outputs:
sdltest.cpp:2:17: fatal error: SDL.h: No such file or directory
#include <SDL.h>
^
compilation terminated.
if I change to #include <SDL2/SDL.h> I get the following error:
/tmp/cc05JSKn.o: In function `main':
sdltest.cpp:(.text+0x15): undefined reference to `SDL_Init'
sdltest.cpp:(.text+0x3a): undefined reference to `SDL_CreateWindow'
sdltest.cpp:(.text+0x4a): undefined reference to `SDL_GetError'
sdltest.cpp:(.text+0x6d): undefined reference to `SDL_Delay'
sdltest.cpp:(.text+0x79): undefined reference to `SDL_DestroyWindow'
sdltest.cpp:(.text+0x7e): undefined reference to `SDL_Quit'
collect2: error: ld returned 1 exit status
Which are the basic functions, so I assume that the shared object libraries are not linked correctly.
I also tried: g++ -Wall sdltest.cpp -o outsdl -I /usr/local/include -L /usr/local/lib
to specify the paths, but again I get:
sdltest.cpp:2:17: fatal error: SDL.h: No such file or directory
#include <SDL.h>
^
compilation terminated.
The only command that worked and successfully compiled, is when using pkg-config g++ sdltest.cpp -o outsdl $(pkg-config --cflags --libs sdl2)
Therefore, I have the following questions:
1) Why is pkg-config necessary and how do compilation and linking flags work?
2) Is it possible to do something else in order to make the compilation command simpler?
3) (if not explained previously) What is the difference between pkg-config and using -I and -L which do not work?
4) what does $(...) actually do in the command line and is it completely the same as `...` ?
Thank you.
The pkg-config command is a more-or-less cross-platform or cross-distro way to provide the correct flags to your compiler to allow it to find header and library files. That way, your system can store files in different locations and everyone can use the same commands to compile your code. It also helps resolve any special requirements of the library you're trying to use.
Using $() is the same as using backticks, so you can execute what is inside the parentheses in order to see what extra arguments are being passed to your compiler to make it work. Here is what I get on my machine when I run pkg-config --cflags --libs sdl2:
-D_REENTRANT -I/usr/include/SDL2 -lSDL2
The reason you're getting SDL.h: No such file or directory is because pkg-config adds -I/usr/include/SDL2 to the include search paths so you can include SDL.h in your code (without the SDL2 subdirectory).
The reason you get undefined reference errors is because you don't have -lSDL2 (which tells the compiler to link libSDL2).
I tried to compile atk 2.7.91 from source. Since I am working on an older ubuntu system there are no recent packages for the required glib version. So I just downloaded glib 2.35.8 and did successfully ./configure and make for it (I don't want to install it system-wide so I didn't do make install).
Suppose this glib is in /foobar/glib-2.35.8. Now I cd to /foobar/atk-2.7.91 and export the PKG_CONFIG_PATH: export PKG_CONFIG_PATH=/foobar/glib-2.35.8:$PKG_CONFIG_PATH.
Then
pkg-config --modversion glib-2.0
tells me:
2.35.8
But when I do ./configure I get the error message:
checking for GLIB - version >= 2.31.2... no
*** Could not run GLIB test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GLIB is incorrectly installed.
configure: error:
*** GLIB 2.31.2 or better is required. The latest version of
*** GLIB is always available from ftp://ftp.gtk.org/. If GLIB is installed
*** but not in the same location as pkg-config add the location of the file
*** glib-2.0.pc to the environment variable PKG_CONFIG_PATH.
cat config.log |grep glib gives:
configure:12143: checking for GLIB - version >= 2.31.2
configure:12258: gcc -o conftest -g -O2 -Wall -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES conftest.c -L/usr/local/lib -lgobject-2.0 -lglib-2.0 >&5
conftest.c:25:18: fatal error: glib.h: No such file or directory
| #include <glib.h>
| fclose (fopen ("conf.glibtest", "w"));
| if ((glib_major_version != 2) ||
| (glib_minor_version != 35) ||
| (glib_micro_version != 8))
| printf("\n*** 'pkg-config --modversion glib-2.0' returned %d.%d.%d, but GLIB (%d.%d.%d)\n",
| glib_major_version, glib_minor_version, glib_micro_version);
| printf ("*** to remove the old version of GLib. You may also be able to fix the error\n");
| else if ((glib_major_version != GLIB_MAJOR_VERSION) ||
| (glib_minor_version != GLIB_MINOR_VERSION) ||
| (glib_micro_version != GLIB_MICRO_VERSION))
| printf("*** GLIB header files (version %d.%d.%d) do not match\n",
| GLIB_MAJOR_VERSION, GLIB_MINOR_VERSION, GLIB_MICRO_VERSION);
| glib_major_version, glib_minor_version, glib_micro_version);
| if ((glib_major_version > major) ||
| ((glib_major_version == major) && (glib_minor_version > minor)) ||
| ((glib_major_version == major) && (glib_minor_version == minor) && (glib_micro_version >= micro)))
| printf("\n*** An old version of GLIB (%u.%u.%u) was found.\n",
| glib_major_version, glib_minor_version, glib_micro_version);
| printf("*** You need a version of GLIB newer than %u.%u.%u. The latest version of\n",
| printf("*** GLIB is always available from ftp://ftp.gtk.org.\n");
| printf("*** of GLIB, but you can also set the PKG_CONFIG environment to point to the\n");
configure:12304: gcc -o conftest -g -O2 -Wall -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES conftest.c -L/usr/local/lib -lgobject-2.0 -lglib-2.0 >&5
conftest.c:25:18: fatal error: glib.h: No such file or directory
| #include <glib.h>
| return ((glib_major_version) || (glib_minor_version) || (glib_micro_version));
*** GLIB 2.31.2 or better is required. The latest version of
*** GLIB is always available from ftp://ftp.gtk.org/. If GLIB is installed
*** glib-2.0.pc to the environment variable PKG_CONFIG_PATH.
ac_cv_env_PKG_CONFIG_PATH_value=/foobar/glib-2.35.8/:
GLIB_CFLAGS=''
GLIB_COMPILE_RESOURCES=''
GLIB_GENMARSHAL=''
GLIB_LIBS=''
GLIB_MKENUMS=''
GLIB_PACKAGES='gobject-2.0'
GLIB_REQUIRED_VERSION='2.31.2'
PKG_CONFIG_PATH='/foobar/glib-2.35.8/:'
Any idea what's wrong here and how to fix it?
SHORT ANSWER
As (almost) always the Manual is your friend. Try taking a look at man pkg-config you'll see it's the .pc files that pkg-config needs to perform it's job. glib-2.0.pc in your case. Unfortunately it's not as easy as just pointing to the location, where it is stored, but leave that for the long answer at the end and take a look at the manual page for a while first.
pkg-config retrieves information about packages from special
metadata files. These files are named after the package, and has a
.pc extension. On most systems, pkg-config looks in and for these
files. It will additionally look in the colon-separated (on Windows,
semicolon-separated) list of directories specified by the
PKG_CONFIG_PATH environment variable.
The package name specified on the pkg-config command line is
defined to be the name of the metadata file, minus the .pc extension.
If a library can install multiple versions simultaneously, it must
give each version its own name (for example, GTK 1.2 might have
the package name "gtk+" while GTK 2.0 has "gtk+-2.0").
I hope you found the funny
On most systems, pkg-config looks in and for these files
line. The result may differ on yours system, but on mine it actually displays it that way, which is most probably a bug.
Nevertheless you can find out the compiled in standard directories by running
pkg-config --variable pc_path pkg-config which for example prints
/usr/local/lib/pkgconfig:/usr/local/lib/pkgconfig/i486-linux-gnu:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/lib/pkgconfig/i486-linux-gnu:/usr/share/pkgconfig
on my system.
LONG ANSWER
To get back to your original question, taking a look at an example .pc file might best explain why your first effort was in vain.
As an example here the contents of the glib-2.0.pc file on my system:
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums
Name: GLib
Description: C Utility Library
Version: 2.24.2
Libs: -L${libdir} -lglib-2.0
Libs.private:
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
As you will hopefully see the whole pathes are all hardwired. Don't get confused by ${libdir} ... and the like. Taking a closer look you will see they are all constructed from prefix=/usr in the first line.
The reason trying to just point PKG_CONFIG_PATH to the build directory of your glib won't work as the path specified in the .pc ist the installation directory and not the location of your build directory.
That's why your pkg-config --modversion test ran just fine: The .pc file was indeed found and contained the given information, but the compilation failed: the .pc file was found as in the first case, but the pathes given in the .pc file were simply wrong.
No one can forbid you to just change the directories given in the .pc to any path you like, so in fact you could make the fresh built library work in its build directory by manually fixing the pathes given in the .pc file.
At least if the library itself doesn't contain any hardwired pathes, but that would only be a problem at runtime not while linking.
To even solve the last puzzle - how the the hell could the .pc file know where it is going to be installed to give the right prefix?
Just take a look at your source directory.
Acompanying your glib-2.0.pc file you'll find a file called glib-2.0.pc.in there, with content like that given below:
prefix=#prefix#
exec_prefix=#exec_prefix#
libdir=#libdir#
includedir=#includedir#
glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums
Name: GLib
Description: C Utility Library
Version: #VERSION#
Requires.private: #PCRE_REQUIRES#
Libs: -L${libdir} -lglib-2.0 #INTLLIBS#
Libs.private: #G_THREAD_LIBS# #G_LIBS_EXTRA# #PCRE_LIBS# #INTLLIBS# #ICONV_LIBS#
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include #GLIB_EXTRA_CFLAGS#
The whole #....# placeholders where filled in at configure time, when you were running configure. i.e. #prefix# was filled with the argument given as --prefix= on the command line, while others like #NTLLIBS# were filled with parameters detected by the configure script.
You need to install the glib somewhere, you can't just point ATK at the Glib build directory. You can install it somewhere private like ~/install by
./configure --prefix=/home/<username>/install
(configure doesn't like ~ IIRC)