I am following this guide in order to build Opencascade frmo source:
https://github.com/tpaviot/oce/blob/master/BUILD.MINGWw64.md
I have done everything up to the MSYS part.
The CMake configuration and generation was succesfull.
I now have a folder with all the things that CMake generated.
So i start MSYS2, and i cd into that directory.
Then i type make.
This is what i get:
User1#User1-PC MSYS ~/Desktop/OpenCascade project/oce/BUILD
$ make
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\User1\Desktop\OpenCascade project\oce\BUILD>
As you can see, nothing happens, no compilation. There is a prompt for me to type. But nothing gets executed.
EDIT:
*I redid the proccess in a new directory, so that no space characters exist in my directory. Problem still remains.
*When i run make --version, i get this:
$ make --version
GNU Make 4.3 Built for x86_64-pc-msys Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
*When i exit the prompt (CONTROL + C) i get this:
C:\Users\User1\Desktop\OPENCAS\oce\BUILD>make: *** [Makefile:1734: cmake_check_build_system] Interrupt
*These are the contents of the makefile, line 1734:
$(CMAKE_COMMAND) -S$(CMAKE_SOURCE_DIR) -B$(CMAKE_BINARY_DIR) --check-build-system CMakeFiles\Makefile.cmake 0
*When i run make VERBOSE=1, i get this:
User1#User1-PC MSYS ~/Desktop/OPENCAS/oce/BUILD
$ make VERBOSE=1
"C:\Program Files\CMake\bin\cmake.exe" -SC:\Users\User1\Desktop\OPENCAS\oce -BC:\Users\User1\Desktop\OPENCAS\oce\BUILD --check-build-system CMakeFiles\Makefile.cmake 0
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
Related
I'm building POCO library 1.6.0 under MinGW32, environment: Windows 7 Ultimate 32-bit, shell: MSYS. Successfully executed ./configure.
$ ./configure
Configured for MinGW
Contents of config.make:
POCO_CONFIG = MinGW
POCO_BASE = /c/dev/poco
POCO_BUILD = /c/dev/poco
POCO_PREFIX = /usr/local
POCO_FLAGS =
OMIT =
export POCO_CONFIG
export POCO_BASE
export POCO_BUILD
export POCO_PREFIX
export POCO_FLAGS
After launching mingw32-make I'm getting:
$ mingw32-make --debug -w
GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
File `poco' does not exist.
File `libexecs' does not exist.
File `Foundation-libexec' does not exist.
Must remake target `Foundation-libexec'.
Invoking recipe from Makefile:69 to update target `Foundation-libexec'.
mingw32-make: Entering directory `c:/dev/poco'
C:/app/MinGW/bin/mingw32-make -d -C /c/dev/poco/Foundation
GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
mingw32-make: Entering an unknown directory
mingw32-make: *** /c/dev/poco/Foundation: No such file or directory. Stop.
mingw32-make: Leaving an unknown directory
mingw32-make: *** [Foundation-libexec] Error 2
mingw32-make: Leaving directory `c:/dev/poco'
The problem is in
mingw32-make: Entering an unknown directory
mingw32-make: *** /c/dev/poco/Foundation: No such file or directory. Stop.
because /c/dev/poco/Foundation does exist:
$ ls
CHANGELOG LICENSE VERSION build_vs110.cmd config.make
CMakeLists.txt MANIFEST XML build_vs120.cmd configure
CONTRIBUTORS Makefile build build_vs90.cmd contrib
CppUnit NEWS build_CE_vs90.cmd buildwin.cmd doc
DLLVersion.rc Net build_vcexpress2008.cmd cmake libversion
Foundation README build_vcexpress2010.cmd components patches
JSON Util build_vs100.cmd config.build
I was modifying makefile to change directory to other sub-folders, no joy. It seems like something prevents mingw32-make from changing directory. Also can confirm that
cd /c/dev/poco/Foundation
works fine.
Tried with make, result is the same:
$ make --debug -w
GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
File `poco' does not exist.
File `libexecs' does not exist.
File `Foundation-libexec' does not exist.
Must remake target `Foundation-libexec'.
Invoking recipe from Makefile:69 to update target `Foundation-libexec'.
make: Entering directory `c:/dev/poco'
C:/app/MinGW/msys/1.0/bin/make -d -C /c/dev/poco/Foundation
GNU Make 3.82
Built for i386-pc-mingw32
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
make: Entering an unknown directory
make: *** /c/dev/poco/Foundation: No such file or directory. Stop.
make: Leaving an unknown directory
make: *** [Foundation-libexec] Error 2
make: Leaving directory `c:/dev/poco'
There are no obvious reasons for mingw32-make to fail as path does not have spaces.
What I have missed? Any suggestions welcome.
The path /c/dev/poco/Foundation does not mean what you seem to think, in the context of mingw32-make.exe. See, mingw32-make.exe is a native Windows application, so it definitely will not understand an MSYS specific path such as /c/dev/poco/Foundation; rather, it will interpret it "as is", as c:/c/dev/poco/Foundation, (assuming your current working drive is c:), which I'm sure is not what you intended.
You do seem to be using MSYS as your shell, so why are you using mingw32-make.exe anyway? Use the make.exe that MSYS itself provides; it does understand MSYS paths.
Do note that, if you run make --version from the MSYS shell, you should see, (at this time of writing):
$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i686-pc-msys
In your updated question, you show an example of running make.exe, which clearly is not this MSYS version; it appears that you have placed an alternative version of make.exe -- perhaps even a copy of mingw32-make.exe itself, for the output is identical -- in some directory which precedes the MSYS version in your $PATH. You should delete this non-MSYS version of make.exe; the entire purpose in calling the MinGW version mingw32-make.exe is to avoid this very conflict. When you run make from the MSYS shell, you want the MSYS version, and not some mingw32-make.exe clone.
I am currently recompiling hunspell from the git source downloaded from fedora as follows:
git://pkgs.fedoraproject.org/hunspell.git
As mentioned by the steps in HACKING, I installed all prerequisite and execute the build commands:
autoconf && ./configure && make
And I received this error message:
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal-1.13 -I m4
/bin/bash: aclocal-1.13:命令找不到 (command not found)
Makefile:463: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 127
My computer has automake 1.14 installed.
tom#bktkowks04:~/Development/hunspell$ aclocal --version
aclocal (GNU automake) 1.14.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Tom Tromey <tromey#redhat.com>
and Alexandre Duret-Lutz <adl#gnu.org>.
tom#bktkowks04:~/Development/hunspell$ which aclocal
/usr/bin/aclocal
tom#bktkowks04:~/Development/hunspell$
Which the offending statement happends when the system is "make"ing. Is there anyway for me to tell make to locate my aclocal? I tried to trace the steps when making. Shall I post the steps listed?
Thanks all.
I haven't a clue when it comes to building makefiles - I am trying to build luafilesystem in Windows 7 x86 for use with Lua for Windows. I have scoured the internet for tutorials but I just can't figure it out. I got as far as to run NMAKE in the Developer Command Prompt but I received the following error:
C:\Users\Me\Desktop\luafilesystem-master\luafilesystem-master>nmake -f Makefile.win
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /Fosrc\lfs.obj /MD /O2 /I"c:\lua5.1\include" src\lfs.c
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
lfs.c
src\lfs.c(63) : fatal error C1083: Cannot open include file: 'lua.h': No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.
I'm not sure what I'm doing wrong. There was no lua.h in the set of files I downloaded directly from the official LuaFileSystem repository.
All I want is to install lfs to use in lua. If you can't figure out what I'm doing wrong but happen to know an easier way, please share. I hope I've provided enough information. Thanks.
You need to have the Lua interpreter you are compiling against to be compiled and available on your computer to access its header files (lua.h and few others) and Lua library/dll files. After you compile the right version of Lua interpreter you need (whether Lua 5.1 or Lua 5.2), set the environmental variables (or update the paths in the make file) LUA_LIBDIR, LUA_INC and LUA_LIB to point to your lua-folder, lua-folder\src, and the lua lib correspondingly.
I am having problems running verify_tools to make a Wireshark build on Windows. The makefile fails with the following errors about not being able to find a file.
C:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
tools/win64-setup.sh: line 12: /cygdrive/c/Development/wireshark/tools/win-setup: No such file or directory
tools/win64-setup.sh: line 12: exec: /cygdrive/c/Development/wireshark/tools/win: cannot execute: No such file or directory
tools/win64-setup.sh: line 12: /cygdrive/c/Development/wireshark/tools/win-setup: No such file or directory
tools/win64-setup.sh: line 12: exec: /cygdrive/c/Development/wireshark/tools/win: cannot execute: No such file or directory
NMAKE : fatal error U1077: 'C:\Users\indiv\apps\cygwin\bin\bash.EXE' : return code '0x7e'
Stop.
To debug, I changed win64-setup.sh and made it print WIN_SETUP.
echo WIN_SETUP: [$WIN_SETUP]
exec $WIN_SETUP $#
The results were bizarre. Possibly because of some end-of-line issue.
C:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
]IN_SETUP: [tools/win-setup.sh
How can I fix or work around this problem?
The Wireshark build relies on all its supporting utilities coming from cygwin, except for cl, link, and nmake. Your path is set up such that some supporting utilities are coming from elsewhere in your environment. Like from an install of gnuwin32 or something.
For explanation purposes, let's say the variable CYGWIN is set to your cygwin path, like c:\cygwin\bin.
You are probably doing something like this, as suggested by the Wireshark wiki:
set PATH=%PATH%;%CYGWIN%
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x64
Instead of doing it that way, move cygwin earlier in the path search order so that executables always come from there. Then set up your Windows build environment so that Microsoft's link comes before cygwin's link.
set PATH=%CYGWIN%;%PATH%
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x64
Don't forget when you make these changes to restart your shell to wipe the old environment completely because SetEnv.cmd may have cached the old environment, which will prevent you from changing %PATH%.
And then you get this instead when you run the verify_tools rule:
c:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Checking for required applications:
cl: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/cl
link: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/link
nmake: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/nmake
bash: /usr/bin/bash
bison: /usr/bin/bison
flex: /usr/bin/flex
env: /usr/bin/env
grep: /usr/bin/grep
/usr/bin/find: /usr/bin/find
peflags: /usr/bin/peflags
perl: /usr/bin/perl
sed: /usr/bin/sed
unzip: /usr/bin/unzip
wget: /usr/bin/wget
I have the following versions of Cygwin, yasm, gcc, and gdb:
CYGWIN_NT-5.1 Thorondor 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
yasm 1.1.0.2352
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
I've compiled vp8 using the following commands:
$ ./configure --enable-debug
$ make
However when I try to debug using GDB, I get the following error:
$ gdb simple_decoder.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/
gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
Dwarf Error: bad offset (0x4c4000) in compilation unit header (offset
0x0 + 6) [in module /cygdrive/
c/work/vp8/csim/build/simple_decoder.exe]
(gdb) q
Can someone help me out with this?
Thanks,
Arjun
Your compiler and binutils are too old. This was solved circa 2000, the fault comes from the linker (see http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00768.html)