I have installed the latest version of Cygwin, selecting the following packages during setup:
libgcc1
gcc
gcc-core
And created a file (test.c) with only this line:
#include <link.h>
Then ran the following from my Cygwin bash:
$ gcc test.c
... but got this error:
test.c:1:18: link.h: No such file or directory
Any ideas how I can fix it?
Cygwin is based on the Win32 subsystem, which means it uses Windows' executable format (COFF) and dynamic linker, i.e. it does not have an ELF dynamic linker. Hence providing the ELF-specific <link.h> would probably make little sense.
Related
I'd like to specify GCC's search directory for the startfile and
endfile: crt1.o, crti.o and crtn.o. Passing -B on the command line to
the GCC driver works, but is inconvenient. How do I modify the specs
file (lib/gcc/x86_64-unknown-linux-gnu/4.9.2/specs) to specify the search path for startfile?
I tried adding the -B option to the startfile spec and got the error:
ld: unrecognized option '-B/gsc/btl/linuxbrew/lib'
I then tried adding the -B option to the cc1 spec and got the error:
cc1: error: command line option '-B/gsc/btl/linuxbrew/lib' is valid
for the driver but not for C
If it's not possible to do this via the specs file, is there an environment variable or a configure option to GCC that accomplishes the same goal?
I've installed a recent version of glibc in my home directory. Everything's working great. I've modified the specs file to link against the new version of glibc, but it's still linking against the old system version in /usr of startfile and endfile.
Here's a the unanswered question on the gcc-help mailing list. Here's a related Linuxbrew bug, gfortran is broken with stand alone Linuxbrew, and a proposed fix, gcc, binutils: link to Cellar instead of system libs.
Thanks,
Shaun
You can use an absolute path in the *startfile: and *endfile: sections in the specs file, instead of the default relative paths. This will override GCC's choice of the default location.
As per https://wiki.debian.org/Multiarch/LibraryPathOverview, gcc will look for startup files such as crt1.o in $(sysroot)/lib, so you can specify the --sysroot option when running gcc, or compile gcc with --with-sysroot.
When I run
gcc test.c
in the terminal of msys,
I get the error
test.c:1:18: fatal error: x264.h: No such file or directory
#include <x264.h>
I can find the x264.h in /local/include
$ ls /local/include/
x264.h x264_config.h
Why MinGW gcc doesn't search the default place?
It's not a "default place" for MinGW GCC. The fact that you're calling native Win32 GCC from the MSYS shell does not mean it knows about these Unix paths MSYS conjures up.
Either install to the / directory or add your 3rd party library directory to the include paths on the commandline:
-I/local/include
Note the above only works from within the MSYS shell.
I downloaded
Ruben’s build of
Cygwin GCC.
However upon running it seems unable to compile any files
$ touch foo.c
$ gcc foo.c
gcc: error: spawn: No such file or directory
As a workaround, I found this to work
i686-w64-mingw32-gcc foo.c
I had the same problem and solved it by installing the g++ package in addition to gcc-core
I had this same problem on Cygwin64, and the solution was PATH related..kinda.
Turns out, there are copies of gcc in /usr/bin and /bin (at least, there is in my install).
Executing /bin/gcc failed with the error above -- I'm guessing due to incorrectly assumed relative paths???
Executing /usr/bin/gcc works as expected!
In my case, the "problem" was that I had inadvertently injected "/bin" into my PATH environment variable, resulting in /bin/gcc being executed, instead of /usr/bin/gcc. Removing the "/bin" from the path solved the problem.
Still unclear why there are two gcc binaries (which appear to be identical) in different places... but maybe the Cygwin gurus can answer that; or maybe my installation is just foo-barred.
Ruben's builds are not Cygwin GCC packages, rather they are cross-compilers which run on various platforms but target native Windows using the MinGW-w64 toolchain.
In any case, you shouldn't be using them on Cygwin. If you want to compile Cygwin executables, install the gcc4 packages; if you want to cross-compile for Windows, install the mingw64-i686-gcc (for Win32) or mingw64-x86_64-gcc (for Win64) packages instead.
Gcc isn't really the compiler. It's a front end program that orchestrates the execution of any necessary compiler, assembler, and linker components. Typically these others are separately compiled programs.
So, gcc is trying (kind of) to tell you that it can't find the compiler. I guess it needs to be on your PATH or in an expected location.
If you are executing this from a Windows DOS box then it definitely needs a windows PATH setting.
I like to install Cygwin, making sure to include rxvt. At that point, you can configure a purely sh(1) path and your environment is rather more civilized.
I had the same error when I tried to extract a couple of executables from cygwin installation dirctory and copied them into another location.
strace shows me the file which was not found by spawn:
/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
When I copied cc1.exe into the location relative to
<dir with sh.exe and cpp.exe>/../lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
it works fine.
This error occurs whenever cygwin cc can't find a required file.
For those running stuff within cygwin's bin directly from a Windows shell, a gotcha to watch out for is that Windows allow you to run programs from the command line like this:
e:cyg/bin/gcc -flags
Notice that there is no slash between e: and cyg.
So this command would successfully start cygwin gcc from the Windows shell, but halfway through the run it will error out because some component(s) of gcc will utilize the first argument of the input e:cyg/bin/gcc and unlike mingw, this is not a valid path for cygwin gcc.
This can be fixed simply by changing the command to:
e:/cyg/bin/gcc -flags
Notice the slash in between e: and cyg.
A similar gotcha is due to Windows allowing paths like e:/../folder1 as an alternative to e:/folder1. Windows does not give you an error if you are at the root folder and try to go up another folder using ...
So you could start running cygwin gcc using the command:
e:/../cyg/bin/gcc -flags
..or even:
e:/../../../../../../../../../cyg/bin/gcc -flags
However, it would fail halfway with gcc: error: spawn: No such file or directory because some component(s) of cygwin gcc would attempt to run gcc using the first argument of the command input itself, and unlike mingw, e:/../cyg/bin/gcc is not recognized as a valid path by cygwin because you are going up a folder when there's no folder to go up to.
As like above, this can be fixed by keeping the path valid:
e:/cyg/bin/gcc -flags
Make sure the source file extension is in lowercase (i.e. main.c, not main.C):
$ gcc -o main main.C
$ gcc: error: spawn: No such file or directory
$ gcc -o main main.c
$ # all good
This only refers to the case of the extension as given to the gcc, the actual source file can have the extension in whatever case you want.
Explanation: This is from my experimenting with cygwin and gcc, I don't know the actual reason for this behavior.
I am using gcc/g++ to compile c/c++ applications - living on OpenSuSe btw.
Is there any way (some option i guess) so that g++ will produce an executable suitable for windows ?
You can search for a mingw32 package in OpenSuSE (I know there is one for Debian) or install it manually. Then if you have a configure script the command line would be something like this in order to have make use the MinGW cross-compilation toolchain:
./configure --prefix=/usr/local --target=i386-mingw32
mingw.org also has a tutorial on building a cross compiler, don't know if that works.
(As an aside: Some websites point to mirzam.it.vu.nl/mingw containing MinGW RPM packages but it seems like that site is down.)
You'll have to be running g++ on Windows to get a Windows executable out of the other end.
Check out mingw or cygwin.
Check out MinGW Cross and related links:
http://www.nongnu.org/mingw-cross-env/#see-also
I have a problem installing PL/Ruby for PostgreSQL 8.4 on Windows XP
PostgreSQL 8.4 is installed and working OK
Ruby-186-27 is installed and working OK
I have MinGW installed and I'm using MSYS as the command line shell
I have downloaded plruby-0.5.3 and unzipped.
My PostreSQL is in C:\Program Files\PostgreSQL\8.4
I've created a record in MSYS fstab file
c:/Progra~1/PostgreSQL/8.4 /usr/local/pgsql
I've tried calling the makefile as follows:
Running the following from the plruby-0.5.3 directory
ruby extconf.rb --with-pgsql-dir=/usr/local/pgsql
I've also tried running with
--with-pgsql-include=/usr/local/pgsql/include
--with-pgsql-include=/usr/local/pgsql/include/server
and also variations on the above i.e. using MSDOS Commands, using environment variables to pass file path, using MS DOS style directory names
The response I always get is:
have_header: checking for catalog/pg_proc.h... --------------------------- no
and then something like
"cl -nologo -E -I. -I"c:/Program Files/Ruby/lib/ruby/1.8/i386-mswin32" -I. -Ic:/Progra~1/PostgreSQL/8.4/include/server -MD -Zi -O2b2xg- -G6 conftest.c -P"
checked program was:
/* begin /
1. #include
/ end */
I'm getting pretty much the same output each time, I've checked and the pg_proc.h file is indeed in c:/Progra~1/PostgreSQL/8.4/include/server in sub-directory catalog
I've tried googling for an answer and it seems that quite a few people have had a problem with compiling Ruby shared libary on Windows in general with this type of issue, and others had issues creating PL/Ruby but I haven't found an answer anywhere on how to resolve this issue.
Thanks in advance for any help you may be able to give.
That looks like you're trying to run something based on autoconf using the MSVC compiler. Last I checked, that was not supported by autoconf. I think autoconf requires mingw and gcc, not MSVC.