I compile code with g++ -Wno-nonnull and get
cc1plus: warning: command line option "-Wno-nonnull" is valid for C/ObjC but not for C++
but then anyway
foo.cxx:455:3: error: null argument where non-null required (argument 2)
The compiler is:
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.5.1 20101208 [gcc-4_5-branch
revision 167585] (SUSE Linux)
For better or worse I do have to support this old compiler. The code compiles fine on g++ 9.2 with -Wno-nonnull.
In man, -Wnonnull is listed among all the (assumably for all languages) "Warning" and not as a "C and Objective-C-only Warning".
Later in the man page, I see -Wnonnull (C and Objective-C only) as the entry for this option specifically.
Any suggestions?
Related
Using MSYS2 (version x86_64-20160205) on Windows 7 64bits, I'm trying to compile corkscrew.
Here is the output:
$ ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) no
checking for working aclocal... found
checking for working autoconf... missing
checking for working automake... found
checking for working autoheader... missing
checking for working makeinfo... missing
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking how to run the C preprocessor... (cached) gcc -E
checking for function prototypes... yes
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.
And the content of config.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
configure:556: checking for a BSD compatible install
configure:609: checking whether build environment is sane
configure:666: checking whether make sets ${MAKE}
configure:712: checking for working aclocal
configure:725: checking for working autoconf
configure:738: checking for working automake
configure:751: checking for working autoheader
configure:764: checking for working makeinfo
configure:783: checking for gcc
configure:896: checking whether the C compiler (gcc ) works
configure:912: gcc -o conftest conftest.c 1>&5
configure:909:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(){return(0);}
^
configure:938: checking whether the C compiler (gcc ) is a cross-compiler
configure:943: checking whether we are using GNU C
configure:971: checking whether gcc accepts -g
configure:1006: checking for gcc option to accept ANSI C
configure:1083: checking how to run the C preprocessor
configure:1165: checking for function prototypes
configure:1327: checking for gcc
configure:1440: checking whether the C compiler (gcc -g -O2 ) works
configure:1456: gcc -o conftest -g -O2 conftest.c 1>&5
configure:1453:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(){return(0);}
^
/usr/lib/gcc/x86_64-pc-msys/5.3.0/../../../../x86_64-pc-msys/bin/ld: cannot open output file conftest.exe: Permission denied
collect2: error: ld returned 1 exit status
configure: failed program was:
#line 1451 "configure"
#include "confdefs.h"
main(){return(0);}
I've tested this answer without any success. Or to be more precise, it goes to the next step (which is failing at detecting my system, which is more a corkscrew's config issue I think) randomly...
This is not a rights problem as I have all the rights on that folder and I use my user to execute ./configure.
Any idea?
It looks like ld is having trouble creating an executable file due to permission problems. Try building the program in a folder that you are sure that you own (like C:\Users\yourusername) or try adjusting the permissions for the folder you are building in.
I have several binaries compiled with gcc/g++ and others compiled with clang/clang++.
So far i have tried:
strings -a ./myBinary | grep -i clang
objdump -s --section .comment ./myBinary
readelf -p .comment ./myBinary
and each one of this command fails to recognize the binaries produced by clang, and each file produced by Clang is recognized as produced by gcc and basically all my binaries are produced by the same compiler according to this tools.
Does Clang puts the same signature as GCC ? How i can get informations about what compilers have generated that binaries ?
Thanks.
I guess it's a duplicate of stackoverflow.com/questions/43523698/clang-appears-to-use-gcc
It seems that if you link against a glibc built by GCC, the latter takes the credits.
I'm learning Objective-C language. Since I don't have a Mac, I'm compiling and running my code within Ubuntu 11.04 platform.
Until now, I was using gcc to compile. I've installed GNUStep and all was working. But then I started to try some Objective-C 2.0 features, like #property and #synthesize, that gcc does not allow.
So I tried to compile the code with Clang, but it seems that it is not correctly linking my code with the GNUStep libraries, not even with a simple Hello world program.
For example, if I compile the following code:
#import <Foundation/Foundation.h>
int main(void) {
NSLog(#"Hello world!");
return 0;
}
The output of the compiler is:
/tmp/cc-dHZIp1.o: In function `main':
test.m:(.text+0x1f): undefined reference to `NSLog'
/tmp/cc-dHZIp1.o: In function `.objc_load_function':
test.m:(.text+0x3c): undefined reference to `__objc_exec_class'
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)
The command I'm using to compile is
clang -I /usr/include/GNUstep/ test.m -o test
with the -I directive to include the GNUStep libraries (otherwise, Clang is not able to find Foundation.h).
I've googled my problem, and visited both GNUStep and Clang web pages, but I haven't found a solution to it. So any help will be appreciated.
Thanks!
The problem was that the library gnustep-base was not being used by the linker. So the solution to this was using the option -Xlinker, that sends arguments to the linker used by clang:
clang -I /usr/include/GNUstep/ -Xlinker -lgnustep-base test.m -o test
The statement "-X linker -lgnustep-base" made the magic. However, I had problems with this command related to the class that represents a string in Objective-C:
./test: Uncaught exception NSInvalidArgumentException, reason: GSFFIInvocation:
Class 'NXConstantString'(instance) does not respond to forwardInvocation: for
'hasSuffix:'
I could solve it adding the argument "-fconstant-string-class=NSConstantString":
clang -I /usr/include/GNUstep/ -fconstant-string-class=NSConstantString \
-Xlinker -lgnustep-base test.m -o test
In addition, I've tried with some Objective-C 2.0 pieces of code and it seems to work.
Thank you for the help!
You can try gcc compiler:
First of all install GNU Objective-C Runtime: sudo apt-get install gobjc
then compile: gcc -o hello hello.m -Wall -lobjc
You are not able to use ObjC 2.0 features because you're missing a ObjC-runtime supporting those. GCC's runtime is old and outdated, it doesn't support ObjC 2.0. Clang/LLVM doesn't have a acompanied runtime, you need to install the ObjC2-runtime from GNUstep (which can be found here: https://github.com/gnustep/libobjc2 ) and reinstall GNUstep using this runtime.
Here are some bash scripts for different Ubuntu versions, that do everything for you:
http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
And please don't try to reinvent GNUstep make, instead, use it:
http://www.gnustep.org/resources/documentation/Developer/Make/Manual/gnustep-make_1.html
If you really don't think so, here is some excerpt from there:
1.2 Structure of a Makefile
Here is an example makefile (named GNUmakefile to emphasis the fact that it relies on special features of the GNU make program).
#
# An example GNUmakefile
#
# Include the common variables defined by the Makefile Package
include $(GNUSTEP_MAKEFILES)/common.make
# Build a simple Objective-C program
TOOL_NAME = simple
# The Objective-C files to compile
simple_OBJC_FILES = simple.m
-include GNUmakefile.preamble
# Include in the rules for making GNUstep command-line programs
include $(GNUSTEP_MAKEFILES)/tool.make
-include GNUmakefile.postamble
This is all that is necessary to define the project.
In your case replace all occurrences of simple with test and you're done
1.3 Running Make
Normally to compile a package which uses the Makefile Package it is purely a matter of typing make from the top-level directory of the package, and the package is compiled without any additional interaction.
I have written some console "Hello world"-like app. and have followed c# cywgwin mono mkbundle windows 7 - cannot compile file answer. But I have got:
$ mkbundle -o Fur Furries.exe --deps -z
OS is: Windows
Sources: 1 Auto-dependencies: True
embedding: C:\Monotest\Furries.exe
compression ratio: 40.43%
embedding: C:\Soft\Mono\lib\mono\4.0\mscorlib.dll
compression ratio: 34.68%
Compiling:
as -o temp.o temp.s
gcc -mno-cygwin -g -o Fur -Wall temp.c `pkg-config --cflags --libs mono-2|dos2un
ix` -lz temp.o
temp.c: In function `main':
temp.c:173: warning: implicit declaration of function `g_utf16_to_utf8'
temp.c:173: warning: assignment makes pointer from integer without a cast
temp.c:188: warning: assignment makes pointer from integer without a cast
/tmp/ccQwnxrF.o: In function `main':
/cygdrive/c/Monotest/temp.c:173: undefined reference to `_g_utf16_to_utf8'
/cygdrive/c/Monotest/temp.c:188: undefined reference to `_g_utf16_to_utf8'
collect2: ld returned 1 exit status
[Fail]
It's in Windows XP.
First of all, prepare development environment:
Install Mono. For example, you have installed it into "C:\Soft\Mono".
Install Cygwin. When selecting which packages to install select following: gcc-mingw, mingw-zlib, pkg-config, nano.
Start Cygwin Bash shell (either using a link or "bash --login -i" command).
Open "$HOME/.bashrc" with "nano" ("nano ~/.bashrc"). Don't use editors which don't preserve end-of-line-s ("CR", "LF", "CR/LF" or other), or it will corrupt the file!
Add following lines to the end of the file:
export PKG_CONFIG_PATH=/cygdrive/c/Soft/Mono/lib/pkgconfig
export PATH=$PATH:/cygdrive/c/Soft/Mono/bin
Restart Cygwin Bash shell.
After that you can compile your assemblies with "mkbundle":
Perform the following command: "mkbundle -c -o host.c -oo bundle.o --deps YourAssembly.exe <additional arguments>". You also may optionally pass "-z" to compress resultant bundle. You should get "host.c" and "bundle.o" files.
In "host.c" you should remove "_WIN32" "branch" (except "#include <windows.h>" one). It doesn't work. You may do it just by adding "#undef _WIN32" right after following lines in it:
#ifdef _WIN32
#include <windows.h>
#endif
So you'll get:
#ifdef _WIN32
#include <windows.h>
#endif
#undef _WIN32
Perform the following command: "gcc -mno-cygwin -o ResultantBundle.exe -Wall host.c `pkg-config --cflags --libs mono-2|dos2unix` bundle.o <additional arguments>". If you added a -z additional argument in step 2, you must add a -lz additional argument in this step.
You will get "ResultantBundle.exe". This is your Mono application packed as standalone executable.
It still requires "mono-2.0.dll" and some additional DLL-s and resources you depended on during development (for example, it may require GTK# native DLL-s) but it doesn't require full Mono runtime to run.
Just wanted to add that if you pass -z to mkbundle then you'll need to pass -lz to gcc. I had some issues getting an application with winforms and net access to work properly, and I had to copy machine.config from C:\Mono\etc\mono\4.0\machine.config to where my application was. I then passed --machine-config machine.config to mkbundle.
All of these steps are pretty confusing and frustrating, why is not as simple as just typing mkbundle --deps app.exe? I tried making a change to the template used by mkbundle and compiling it myself, but it wont run. I've gone as far now as to download the mono source and attempt to build the whole thing, but I doubt it will work. If anyone can explain what the hell is going on with mkbundle to make this so annoying, I'd be interested in contributing.
after you have the temp.o and temp.c, you can add them to visual c++ to make a windows application with other sources.
Using: windows xp, g++ 3.4.4 with cygwin and g++ 3.4.5 with mingw.
I'm compiling a simple unit test class with cppunit.
When I link using g++ 3.4.5 I get a lot of linking errors. When I link with g++ 3.4.4 I don't get any errors and the exe links fine and runs.
I can't seem to trace down the errors, so any thoughts?
Thanks.
EDIT: linking errors: Unreferenced function errors. Like:
SimpleTest.cpp:(.text+0x313): undefined reference to `CppUnit::Message::Message(std::string const&, std::string const&)'
EDIT: cmd line:
g++ -I g:\projects\thirdparty\cppunit-1.12.1\include -L g:\projects\thirdparty\cppunit-1.12.1\lib -l cppunitd -o main.exe main.cpp SimpleTest.cpp
Update: Same code in Visual Studio: No error, unit test runs as expected.
Your problem is likely incorrect link line. The order of sources/object files and libraries on the link line matters. Correct link line:
g++ -I g:\projects\thirdparty\cppunit-1.12.1\include \
-L g:\projects\thirdparty\cppunit-1.12.1\lib \
-o main.exe main.cpp SimpleTest.cpp -lcppunitd
As g++ matures, I'm on 4.2.3, it's type checking has gotten more pedantic and for that matter better. With the little information I'd say it's likely that you should look closely at your calls to these methods. I suspect that the types are not quite right. 3.4.4 doesn't catch it, 3.4.5 does.
....JW
One thing you could perhaps try is to compile with g++ 3.4.5 and/or 3.4.4 on Linux. If the result then is the same, then it is clearly a property of gcc. Otherwise it more sounds like a mingw issue.