I'm trying to build XercesC-3.1.2 with MinGW.
After running $ mingw32-make in the xerces directory, I get the following error:
mingw32-make[4]: Entering directory '/my/path/to/xerces-c-3.1.2/src'
process_begin: CreateProcess(NULL, /bin/mkdir -p xercesc/util, ...) failed.
make (e=2): The system cannot find the file specified.
Following the XercesC build instructions, I'm running the configure script as
$ ./configure CC=mingw32-gcc CXX=mingw32-g++
but without the variable LDFLAGS=-no-undefined. This is contrary to the build instructions in the XercesC webpage because otherwise the configure script will not work because the flag is not recognized by gcc. The configure script seems to run fine, however. After that, running mingw32-make gives the error above.
My mingw32-make and mingw32-gcc versions are
mingw32-gcc/g++ 4.8.1
mingw32-make 3.82.90
I tried adding C:\MinGW\libexec\gcc\mingw32\4.8.1 to my PATH, as suggested by Codeblocks, but had no exit.
I also fresh installed MinGW in another machine that has no other compiler (or Cygwin, or anything) and got the same results.
I guess you are using MSYS to run the configure script, so why are you using mingw32-make for the make step? You should run the make step in MSYS too, and use the make which is provided with MSYS. The error message which you see suggests that mingw32-make is unable to resolve the path to /bin/mkdir, which is an MSYS command, and should not be visible outside the MSYS shell process context.
FWIW, xerces-c-3.1.2 builds OOTB for me, cross-compiling with gcc-4.9.3 and binutils-2.24.1, as follows:
tar xf ~/Downloads/xerces-c-3.1.2.tar.xz
mkdir xerces-c-3.1.2/build
cd xerces-c-3.1.2/build
../configure --build=x86_64-linux-gnu --host=mingw32 --prefix=/mingw --enable-static --enable-shared
...
make LDFLAGS=-no-undefined
make prefix=`pwd`/dist/staged install
Related
I want to build my own operating system ， but how install i686-elf-gcc in manjaro
i I found a tool（https://github.com/lordmilko/i686-elf-tools）, but it can only be run in ubuntu
A simple solution would be to build the compiler yourself. I went through the same thing recently. If you are into operating system development, you won't be able to avoid looking at the compiler in more detail and building cross compilation tools anyway.
Building your own compiler
The build process can be roughly divided into 4 steps:
Install all dependencies necessary for the build. If I remember correctly, you can get everything from the official package sources in Arch Linux. Make sure that these packages/tools are present: make, bison, flex, gmp, mpc, mpfr, texinfo, libisoburn, mtools.
Download the source code of binutils (GNU's assembler and binary tools) and gcc (the GNU compiler collection). I recommend using the newest versions at the bottom of the respective pages.
Decide where your new compiler should be installed. Although it sounds tempting, it should not end up in any system directory, rather somewhere in your home folder. I used $HOME/tools/crc to store my cross-compilation tools. You can at it to your $PATH lateron for convenience.
Do the actual build. First of all: The build takes a while and needs one or the other command line switch. Do not omit any of them. The build may pass and problems may occur later. Just follow the instructions below.
The actual build process
The first thing to do is to compile binutils, because it is needed for the gcc build. For convenience set a few shell variables to minimize error sources:
# This is where the tools will end up
export PREFIX="$HOME/tools/crc"
# Prefix of the produced assemblies (for example i686-elf-gcc)
export TARGET=i686-elf
# Add the new installation to the PATH variable temporarily
# since it is required for the gcc build
export PATH="$PREFIX/bin:$PATH"
Now create a new directory somewhere and extract both the gcc and binutils source code archives in there. You should end up with two subdirectories like yourdir/binutils-x.y.z and yourdir/gcc-x.y.z. It is recommended to do the build in an empty directory, so create yourdir/build-binutils and yourdir/build-gcc as well. Notice: These directories are not placed inside the source directories!
Building binutils
cd into the yourdir/build-binutils directory and run the following commands. Replace the x.y.z part with your version.
../binutils-x.y.z/configure \
--target=$TARGET \
--prefix="$PREFIX" \
--with-sysroot \
--disable-nls \
--disable-werror
make
make install
Now check the installation with which -- $TARGET-as. This will return the location of i686-elf-as, which is the assembler we just build.
Building gcc
cd into the yourdir/build-gcc directory. The process is pretty much the same as with binutils above:
../gcc-x.y.z/configure \
--target=$TARGET \
--prefix="$PREFIX" \
--disable-nls \
--enable-languages=c,c++ \
--without-headers
make all-gcc
make all-target-libgcc
make install-gcc
make install-target-libgcc
Verify the build
Check the installation by invoking i686-elf-gcc --version. If you used the same values as I, this can be done with $HOME/tools/crc/bin/$TARGET-gcc --version.
I'm on Windows 10 and using the latest version of MSYS2 (with gcc installed: pacman -S gcc)
I'm trying to compile mingw-w64-headers and mingw-w64-crt from mingw-w64-v7.0.0
Inside of my MSYS2 installation directory C:\msys2 I have created the folder mingw-w64 which I reference in the prefix argument below.
To compile each of these I use the same steps (replace name of library where appropriate):
mkdir mingw-w64-crt && cd mingw-w64-crt
../mingw-w64-v7.0.0/mingw-w64-crt/configure --prefix=/mingw-w64
make
make install
This works for mingw-w64-headers however for mingw-w64-crt I encounter errors at the make step. Specifically: incompatible types when assigning to type 'mbstate_t' {aka 'struct anonymous'} from type 'int'. A more detailed error image can be found here.
I would appreciate some guidance as to how to proceed.
I suggest that you just open one of MSYS2's MinGW environments (by running mingw32.exe or mingw64.exe) and then install the complete MinGW-w64 toolchain by running this:
pacman -S $MINGW_PACKAGE_PREFIX-toolchain
The toolchain includes GCC, the MinGW-w64 libraries, and the MinGW-w64 headers. If those prebuilt MinGW-w64 things are good enough for you, then you're done.
If you want to compile your own MinGW-w64, then should be able to use the environment you just installed to do it. To double-check that you are using the right toolchain, run which gcc and make sure it returns /mingw64/bin/gcc or /mingw32/bin/gcc.
Performing the following has allowed me to successfully compile:
pacman -S $MINGW_PACKAGE_PREFIX-toolchain
mkdir mingw-w64-crt && cd mingw-w64-crt
../mingw-w64-v7.0.0/mingw-w64-crt/configure --prefix=/mingw-w64 --with-sysroot=/mingw64
make -j %NUMBER_OF_PROCESSORS%
make install
I am using an Ubuntu 20.04 machine with the newest version of platform-tools installed and (I believe) all necessary dependencies.
I created a new directory ~/beta1-kernel-coral and within this directory I cloned the kernel:
git clone -b android-msm-coral-4.14-r-beta-1 https://android.googlesource.com/kernel/msm/
I noticed the clang version used was clang-r383902. I downloaded this directory and extracted it so that I had two separate directories within ~/beta1-kernel-coral: msm and clang-r383902.
From within ~/beta1-kernel-coral/msm, I ran two commands:
make floral_defconfig
make menuconfig
Next, using Nathan Chance's guide from Github, I ran the following command:
PATH="/home/jherwig/beta1-kernel-coral/clang-r383902/android_prebuilts_clang_host_linux-x86_clang-6443078-10.0/bin:/usr/bin:/usr/bin:${PATH}" make -j$(nproc --all) ARCH=arm64 CC=clang CLANG_TRIPLE=aarch64-linux-gnu- CROSS_COMPILE=aarch64-linux-android- CROSS_COMPILE_ARM32=arm-linux-androideabi-
The kernel began compiling until I received the following output:
https://pastebin.com/61pkd6uf
In Nathan's guide, he intructs to use:
PATH="<path to clang folder>/bin:<path to 64-bit gcc folder>/bin:<path to 32-bit gcc folder>/bin:${PATH}" \ ...
Since I installed gcc-multilib, I thought <path to 64-bit gcc folder> and <path to 32-bit gcc folder> would be in /usr/bin. When I type which gcc in terminal I get /usr/bin/gcc.
CAF kernels are NOT mainline kernels and you cannot compile them as such. You must run make distclean and specify an out directory for each make command, including the defconfig
Example:
make O=out
If you do not specify O=out for each make command you'll hit these errors
The value assigned to O can be anything, doesn't have to be out but you cannot build the kernel in the same directory as the source
Change this:
make floral_defconfig
make menuconfig
To this:
make floral_defconfig O=out
make menuconfig O=out
The build it with:
make O=out
Remember to make distclean in the source directory first
I need to compile openssl 1.0.1f version with afl-fuzz and then use it in an application to find heartbleed bug. I have done so far;
Go to openssl1.0.1f directory and run following command
./config CC="afl-gcc" CXX="afl-g++"
./config no-shared no-idea no-mdc2 no-rc5 no-comp enable-tlsext no-ssl2
make depend
make && make install
Everything works fine but during compilation I see gcc -I commands compiling files rather than afl-gcc and I donot see Instrumentation details at the end as I see it in simple programs I compile with afl-fuzz. I am not sure openssl has compiled with gcc or afl-gcc. I have also replaced gcc with afl-gcc in Makefile but no result.
Can someone please explain as in all blogs about openssl and afl-fuzz, I have found these commands only.
Thanks.
I was making a simple mistake of calling ./configure after manually making changes to Makefile. Each ./configure command overwrites previous Makefile. So my step should be in following order.
./config no-shared no-idea no-mdc2 no-rc5 no-comp enable-tlsext no-ssl2
make depend
Manually replace every occurrence of `gcc`to `afl-gcc` in Makefile
make && make install
Thanks.
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.