I was porting a project to Windows using mingw32 and the project depends on a library called libfec. Libfec has a lot of assembly code to optimize the inner workings. In Linux (with GCC 5.4) the library compiles fine. Today I tried to compile it on windows using mingw32 (with as well gcc 5.4) and I got this error:
as -o mmxbfly27.o mmxbfly27.s
mmxbfly27.s: Assembler messages:
mmxbfly27.s:10: Warning: .type pseudo-op used outside of .def/.endef ignored.
mmxbfly27.s:10: Error: junk at end of line, first unrecognized character is `u'
make: *** [mmxbfly27.o] Error 1
The warning about .type happens in Linux as well, but the Error doesn't. I checked the binutils and they're actually different (on linux it was 2.26 and in mingw was 2.25) but the code of libfec is a bit old (few years) and its compilable even with binutils 2.0.
I'm not sure why I can't compile this on windows. The full code is here:
https://github.com/quiet/libfec/blob/master/mmxbfly27.s
I asked a friend that has experience with compilers, and he couldn't find a problem in the code (and it does compile fine in linux).
Ok so the solution was really simple: just comment the .type directive. The PECOFF doesn't need that. Now I'm able to compile and run just fine.
Related
Given a meson-based project where meson.build contains the following line:
cc = meson.get_compiler('c')
How does meson.get_compiler('c') pick a compiler on a system with multiple C compilers? At the time of writing this question, the reference manual does not provide much detail, only...
Returns a compiler object describing a compiler.
Please note I am not trying to force meson to use a specific compiler. Rather, I am trying to understand how this line in meson.build, as it is currently written, will function.
On Windows it tries icl, cl, cc, gcc, clang, clang-cl, pgcc; on Linux it tries cc, gcc, clang, nvc, pgc, icc. That's after it looks for the value of $CC and whatever is in your cross or native file. See the code here.
I am using codeblock 13.12 and it uses mingw (GCC 4.7 & 4.8 Series)
It supports call by reference (func1(int &a)) eventhough I am selecting C project and not CPP project. If I am not mistaken, there is no concept of call by reference in C and everything is call by value even if it is making use of pointers.
My question is how to use C only features? Any settings for this? I saw that in toolchain it is using mingw32-gcc.exe for c compilations.
How to know which compiler version (Like C11, C99 etc) it is really using?
Name your files with an extension of .c. And definitely not .cc or .cpp
Compile with gcc as the command line, not g++
And if in doubt, use the -std= command line parameter to force the flavor of C you want (e.g. -std=C90, -std=C99, or even -std=C11 ). There's also -ansi.
Also, a cheap and dirty way to validate if your code is getting compiled as C and not C++ is to add this block of code within your source code. If it's C++, then the compiler will generate an error.
#ifdef __cplusplus
int compile_time_assert[-1];
#endif
I downloaded and compiled the header which is used in pthread functions. But one function is missing and that is *__lll_robust_lock_wait*. Now I noticed that there is an assembly code header out there, . I downloaded this and tried to compile it using the usual the compile command "as lowlevelrobustlock.S" and I got nearly 100 compiler errors. Is there a simpler version of the function I mentioned that will actually compile and be useful?
The assembly code header can be found here
I understand that MINGW-g++ compiles larger executables because it statically links many things. On the other hand MSVC++ links dynamically against DLLs from the VCRedist package, and that is why it produces way smaller executables.
However, is it possible to compile with g++ in a similar manner on windows? Not necessarily MINGW-g++ but something that I can use with Qt Creator (I didn't add Qt as a tag because it's irrelevant to the question).
MinGW is perfectly capable of linking to the msvcrt runtime dynamically. The only mess you're not getting rid of this way is GCC/MinGW startup code, which is not very large.
A small C++ test program (simple iostream hello world program, note: I got the same results for a plain C printf version).
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World!" << endl;
return 0;
}
Commandlines:
g++ main.cpp -MD -Os -s -o test.exe
cl /MD /Os main.cpp /link /out:test2.exe
Executable file sizes:
GCC: 13kB
MSVC: 6kB
Although this is double, all necessary startup code accounts for the large difference; for larger programs, the difference is negligible.
To make a fair comparison between VC++ and MinGW using static linking, I would suggest removing the compiler switch /MD in the command line syntax above. This will cause the Visual C++ compiler to link statically with static libraries instead but still, the Visual C++ compiler will generate a much smaller executable than the one compiled statically with MinGW.
Because the linker used by the Visual C++ compiler has a feature called function-level linking, with this, the linker only links the necessary libraries based on the functions used in your code. Any unreferenced or unused functions will not be linked to the final executable generated resulting in a much smaller statically linked binary.
Going back to the example above using the Visual C++ compiler and this time, using the static linking, the command line syntax would be:
cl /Os main.cpp /link /out:test2.exe
You can notice here that I have removed the /MD switch so that the compiler will use static linking instead of dynamic.
Now, to make a much smaller statically linked executable, I suggest the command line syntax:
cl /Ox main.cpp /link /FILEALIGN:512 /OPT:REF /OPT:ICF /INCREMENTAL:NO /out:test2.exe
If you check the resulting binary, you will notice that it is much smaller which is again, a statically linked executable.
I actually got this idea from the discussion on this website at http://www.catch22.net/tuts/minexe
Most Pascal compilers including Delphi also have the same linking feature and it is known as smart linking but the resulting statically linked executables are much smaller the those produced by the Visual C++ compiler.
The linker used by MinGW is very dumb, it is bloat unaware and therefore, it links many static libraries including those which contains functions or routines which are not used in your source code at all leading to a very bloated statically linked binaries.
I would advise dumping MinGW and use the Visual C++ compiler instead. Even the developer of MinGW doesn't seem to care on reducing code bloat using static linking.
You can use cygwin (www.cygwin.com). They use a runtime DLL much like MSVCRT . Then your program depends on the cygwin runtime, of course (kind of a tautology, sorry).
I am compiling on a 64 bit architecture with the intel C compiler. The same code built fine on a different 64 bit intel architecture.
Now when I try to build the binaries, I get a message "Skipping incompatible ../../libtime.a" or some such thing, that is indicating the libtime.a that I archived (from some object files I compiled) is not compatible. I googled and it seemed like this was usually the result of a 32->64 bit changeover or something like that, but the intel C compiler doesnt seem to support a -64 or some other memory option at compile time. How do I troubleshoot and fix this error?
You cannot mix 64-bit and 32-bit compiled code. Config instructions for Linux are here.
You need to determine the target processor of both the library and the new code you are building. This can be done in a few ways but the easiest is:
$ objdump -f ../../libtime.a otherfile.o
For libtime this will probably print out bunches of things, but they should all have the same target processor. Make sure that otherfile.o (which you should substitute one of your object files for) also has the same architecture.
gcc has the -m32 and -m64 flags for switching from the default target to a similar processor with the different register and memory width (commonly x86 and x86_64), which the Intel C compiler may also have.
If this has not been helpful then you should include the commands (with all flags) used to compile everything and also information about the systems that each command was being run on.