I'm trying to compile a project with MinGW-w64 and I get a file too big error while creating the object code.
I already tried, in vain, to add some compile options to my CMakeLists.txt file as follows:
if(WIN32)
target_compile_options(${target_name} PUBLIC -Wa,-mbig-obj)
endif()
I also tried to append -O2 to such options, but I should really avoid it for my debug and release configurations.
I installed MinGW-w64 and CMake from the MSYS2 package. They're both up to date. MinGW-w64 should have Large File Support, so I'm not sure about the source of the problem. Is MinGW-w64 actually a 32 bit compiler targeting 64 and 32 bit systems? If it was the case, shouldn't LFS prevent file too big errors?
Thanks in advance.
Related
I have never worked with CMake before, so please forgive any rookie mistakes. Most of the following working frame has been given to me by my project group.
The goal is to build GoogleTest into a .dll, to be used in different, indepentent parts of our project. I'm having troubles setting up CMake the right way.
The work-flow so far has been:
Clone gtest from git --> also downloads a CMake List file
Alter variables in CMakeCache.txt to have it produce a Code::Blocks project file
Compile the project file in Code::Blocks
So far, it produces a static library (.a files) that can be used in our project. I'm having troubles genereating .dll files.
Variables I have tried changing:
BUILD_SHARED_LIBS:BOOL=ON --> the files generated by Code::Blocks now have a .dll.a double extension
CMAKE_C_FLAGS and all the corresponding C++ flags where set to -DGTEST_CREATE_SHARED_LIBRARY=1 as given here
CMAKE_EXE_LINKER_FLAGS has been set to -shared to make the linker produce .dll files
I have worked my way through the GoogleTest documentation here and here but in both, building it into a .dll is merely a 2-sentence-topic.
As #Tsyvarev pointed out, the .dll files were created in a (very) different folder.
I am trying to build the Blender project in CLion, and failing with just configuring the IDE.
First, but not so crucial IMO, I am not sure which Architecture should I select in the Settings. By default CLion decided to go with x86, but that sounds like 32bit Windows to me... in 2022?
(But as long as I can build the project I guess win32 should not bother me.)
This seems like a bigger problem:
CMake Warning at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.21/Modules/InstallRequiredSystemLibraries.cmake:601 (message):
system runtime library file does not exist:
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/msvcp140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/vcruntime140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/concrt140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.OPENMP/vcomp140.dll'
...
CMake Error at build_files/cmake/platform/platform_win32.cmake:264 (message):
32 bit compiler detected, blender no longer provides pre-build libraries
for 32 bit windows, please set the `LIBDIR cmake variable` to your own
library folder
All those "missing" files are scattered in the Visual Studio subdirectory "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.30.30704\x86\Microsoft.VC143*" directories, but for some reason CMake "decided" to go with VC142.
1) How does one convince CMake to go with VC143?
2) How does one set the LIBDIR cmake variable?
I suppose this one could go away once the Nr.1 problem gets resolved, but if not... Where should the variable point to, and what would its full name be? Just LIBDIR? (I am seeing CMAKE_INSTALL_ and CMAKE_INSTALL_FULL_ prefixes mentioned in GNUInstallDirs.cmake.)
Anyways, I suspect it should be set here?
So apparently there's a bug in VS2022. This version comes with CRT143 (whatever it is) yet the bundled scripts identify the VS as 2019 which only knows/recognizes CRT up to version 142.
https://developercommunity.visualstudio.com/t/1616850
I am using Header Only Libraries. The libraries are included through Cmake. I am using the g++ Compiler.
Now what I am looking for is to compile the c++ source files via windows cmd. In this moment i am using clion to compile.
Does anyone know how to compile the source files?
If i am compiling the files without cmake , I am getting errors because the program cannot find the libraries.
You do not run a source file, you run an executable produced by a compiler from source file(s)
If you are under a Linux for instance enter the path(s) where the libraries are through the environment variable LD_LIBRARY_PATH
[edit after your remark]
I mean compile
To indicate to g++ where the library are to link use the option -L followed by the path of a directory where the libraries are. If your libraries are on different directories use several time the option, one per directory
I downloaded Codeblocks bundled with GCC from here
The C part is running fine
I read this wiki tutorial which says having GCC will allow me to compile objective C by just adding -lobjc to the compiler options
However, I have followed the steps mentioned in this tutorial and added the -lobjc option, but it doesn't compile
This is the build error message I get in codeblocks:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o
mingw32-gcc.exe: error: CreateProcess: No such file or directory
Process terminated with status 1 (0 minute(s), 2 second(s))
1 error(s), 0 warning(s) (0 minute(s), 2 second(s))
As shown above, it does not show the -lobjc option
I have also tried manually compiling the above program in Windows cmd by going into the folder containing the .m file. I gave the following command:
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
But I get the same error in cmd
mingw32-gcc.exe: error: CreateProcess: No such file or directory
I also tried
gcc -g -fgnu-runtime -O -c some_class.m
that I got from here, but it gives me the same CreateProcess error. How do I start compiling Objective C code in Windows (preferably using GCC and Codeblocks) ?
--- EDIT 1 ---
I did as suggested in Mike Kinghan's answer below, and uninstalled my older Codeblocks instgallation, then reinstalled MinGW and codeblocks separately. The Codeblocks uninstall removed the Codeblocks folder in Program Files, but when I reinstalled Codeblocks again (version without MinGW bundled together), the "GNU GCC Obj-C" settings I made with the previous installation was still there, along with the -lobjc flag in the "linker settings" tab.
However, the problem is that it's still not working. I get the following error if I try to build from Codeblocks
Goto "Settings->Compiler...->Global compiler settings->GNU GCC Obj-C Compiler->Toolchain executables" and fix the compiler's setup.
Tried to run compiler executable 'C:\Program Files\CodeBlocks\MinGW/bin/mingw32-gcc.exe', but failed!
Skipping... Nothing to be done (all items are up-to-date).
This is what Toolchains executable looks like:
If I try to compile it from cmd by going in to the folder with the .m file and issuing the command
mingw32-gcc.exe -Wall -g -c D:\backup\cb_files\objc_files\test_prog_proj\test_prog.m -o obj\Debug\test_prog.o -lobjc
it gives the error
mingw32-gcc.exe: error: CreateProcess: No such file or directory
What is the problem here?
--- EDIT 2 ---
Following the suggestion in Mike Kinghan's answer I deleted the old instance of "GNU GCC Obj-C Compiler" in the list of compiliers, and recreated with the current version of "GNU GCC Compiler"
However, the program still does not work. This is the message I get in the build log:
-------------- Build: Debug in test_prog_proj (compiler: GNU GCC Obj-C Compiler)---------------
Linking stage skipped (build target has no object files to link)
Nothing to be done (all items are up-to-date).
Cleaning the project and then building it again gives the same message. Trying to run the project anyway gives me a dialog box saying the project is not built, and clicking on Yes to build the project just pops the same "project not built yet" dialog box up again. The file icons in the Workspace tree of the Projects tab also seem to be grayed out:
This is what Toolchain Executable looks like:
I have added -lobjc in Linker Settings as mentioned here as well.
I right clicked the project icon in the Project tree, went to Build Options and added -lobjc in the Linker Settings as well:
What is the problem with this project at the moment?
--- EDIT 3 ---
I ended up completely uninstalling Codeblocks (uninstall from windows start menu, delete codeblocks folder in %APPDATA%), uninstalling MinGW (deleting the c:\MinGW folder) and reinstalling everything from scratch. I followed all the instructions in the Wiki (except the Troubleshooting section, but I think that part is irrelevant) and it still doesn't work (same problem as described in Edit 2 in this post).
How do I get Codeblocks to detect and compile obj-C code? Also, it is not showing me the compiler command line arguments when I try to build it from the Codeblocks interface. Why is this and how can I get it to show me whatever the full command line it is using?
The GCC program we loosely call the "the compiler" - [mingw32-](gcc|g++) -
is actually a compiler/linker frontend that invokes a real language
compiler and/or linker depending on what the input files and commandline options
indicate you want it to do.
Input files with an .m extension indicate they are Objective C source files
that are to be compiled with the GNU Objective C compiler, cc1obj. But you
haven't got it. Hence the failure you see.
A GCC installation will include the C compiler cc1 and, optionally, compilers
for other languages - C++, Fortran, Objective (C|C++), Go ... You say you got your MinGW GCC installation as
bundled with Code::Blocks. That bundled MinGW omits the Objective C compiler, cc1obj , because the maintainers
reckon it a niche language.
Best remove your CB installation and bundled MinGW and then install MinGW GCC independently from
one of the rival projects:-
https://sourceforge.net/projects/mingw-w64/
https://sourceforge.net/projects/mingw/
Run the installer and ensure that you get Objective C as well as any other compilers you
want.
After that, replace your CB installation it with the codeblocks-17.12-setup.exe installer (not codeblocks-17.12mingw-setup.exe),
from https://sourceforge.net/projects/codeblocks/files/Binaries/17.12/Windows/. This installer includes no compilers and
will auto-detect your MinGW installation.
Then proceed as you already did to create a GNU GCC Obj-C compiler setup in the CB IDE.
Later ... still not working
Your GNU GCC Obj-C compiler-setup has persisted from your previous
CB install and has been rendered out-of-date by the fact that your
new MinGW installation is no longer part of Code::Blocks. As you see,
it still looks for the toolchain executables in C:\Program Files\Codeblocks\MinGW,
whereas your new MinGW is somewhere else.
When you reinstalled Code::Blocks you should have seen its attempt to auto-detect compilers,
and that it detected your MinGW toolchain in (say) C:\MinGW. It will have configured
a compiler setup for GNU GCC Compiler on that basis, with the correct path to
the toolchain executables. But it will not have modified any persisting compiler setups that
you created yourself, such as GNU GCC Obj-C.
First check that the auto-detected setup GNU GCC Compiler is good just
by creating a "Hello world" C console project and seeing that you can build it.
I assume you'll be able to, but if not, then go into the GNU GCC Compiler setup
yourself and manually set the Compiler's installation directory correctly.
Then, set the same Compiler's installation directory for your GNU GCC Obj-C
compiler setup.
I compiled wxWidgets 2.8.12 using MinGW. To actually do the build I invoked the autotools build files distributed with wxWidgets through the MSYS shell, using an install prefix of H:\MinGW-libs.
The result of this is that I have a Unix style file tree containing my wxWidgets headers and libs (which are .a files, not .dll) with root directory H:\MinGW-libs.
My problem is that I can't get CMake to find the files. When I try to use the "configure" button in the CMake gui it finds other dependencies (namely boost, for which I had to specify BOOST_ROOT, but it does not find wxWidgets. I see that wxWidgets_ROOT_DIR is an available constant that I can set but none of the obvious choices
H:\MinGW-libs (my install prefix for wxWidgets)
H:\MinGW-libs\lib
H:\MinGW-libs\include
fix the error.
There is an old post on the CMake mailing list about this issue but there isn't actually any information indicating how to fix it in this use case. The only hint I have is that there's a difference between looking for wxWidgets in "Unix style" file trees and "Windows style" file trees.
How can I get CMake to find wxWidgets installed in a Unix style file tree on Windows 7? Is there are way to get CMake to use wx-config? I ask this because from the MSYS command line using wx-config to get lib and header locations works just fine.
From FindwxWidgets.cmake:
if(WIN32 AND NOT CYGWIN AND NOT MSYS)
set(wxWidgets_FIND_STYLE "win32")
else()
if(UNIX OR MSYS)
set(wxWidgets_FIND_STYLE "unix")
endif()
endif()
So Unix-style tree is assumed for the "MSYS Makefiles" generator (cmake -G "MSYS Makefiles") but not for the "MinGW Makefiles" generator.
Which one do you use?