The command g++ -o myprogram myprogram.c -std=c++0x works well on ubuntu but when I try the same with centos it throws me an error cc1plus: error: unrecognized command line option "-std=c++0x". Even google doesn't give the answer. Have anybody experienced it before? Does anybody know the solution?
You most likely have different versions of the compiler on each system, run g++ --version to see which version you're running on each (-std=c++0x is only supported from version 4.4 of g++).
In the CentOS repositories is something called g++44. Yum it, or grab it however makes the most sense to you.
Then, when you build, use g++44... with the rest of your switches. That might help, you never know.
If it works for you then you could remove g++ and symlink g++44.
Related
I need to short circuit some security features in the Debian packaging process. I explain why here, knowing that your first reactions might be "don't disable security features" and "update your program to compile with new gcc."
I have to use gcc-4.6 to compile some libraries (http://pj.freefaculty.org/Swarm) because that is the last version of gcc that provided the traditional Objective-C API. After that, gcc removed the traditional headers. Hence, "upgrade your gcc" is not acceptable because we have a very large code base using the traditional Objective-C.
In Ubuntu 17.04, gcc-4.6 is no longer available, but I've found I can install it by pulling an old version from Ubuntu "trusty". It runs fine. I can compile programs and install them the old fashioned make install way.
However, I run into a problem when building Debian packages. When I run dpkg-buildpackage -rfakeroot, as I usually do to build a package, I hit a failure because the Debian packaging system has inserted CFLAGS that are not legal in gcc-4.6. In particular, the command line includes -Wdate-time and -fstack-protector-strong, both of which are not compatible with gcc-4.6.
Here's a piece of the config.log.
configure:3878: checking whether the C compiler works
configure:3900: gcc -g -O2 -fdebug-prefix-map=/home/pauljohn/LinuxDownloads/Debian/sources/amd64/swarm-Ubuntu17.04/swarm-2.4.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c >&5
cc1: error: unrecognized command line option '-Wdate-time'
cc1: error: unrecognized command line option '-fstack-protector-strong
I've inspected the debian directory with the package and I see that those flags are not manually inserted there. From what I can tell, they come along with dpkg-buildpackage.
This library I'm trying to compile is, well, an old program. Its one on which we worked, in affiliation with the Santa Fe Institute, about 15-20 years ago. It is not reasonable to rewrite this old code to use the new Objective-C interface, so it is important to live within the restriction of gcc-4.6.
So far, the most useful suggestion I've received is to drop the Debian/Ubuntu architecture and shift to a RedHat based one, where older gcc is more easily tolerated. In fact, on RedHat 6, gcc-4.6 would be somewhat ahead of the usual, while I can still install gcc-4.6 on RedHat 7, so far as I can tell. I'd rather not exclude the Ubuntu users, however, by doing that.
Any other ideas about how to navigate this would be appreciated.
The relevant documentation is man 1 dpkg-buildflags
You basically have two options:
override specific build features of the dpkg buildprocess, hoping to remove the right flags
export DEB_BUILD_OPTIONS="hardening=-stackprotectorstrong reproducible=-timeless"
dpkg-buildpackage -rfakeroot
strip specific build flags from specific build variables
export DEB_CPPFLAGS_STRIP="-Wdate-time"
export DEB_CFLAGS_STRIP="-fstack-protector-string"
export DEB_CXXFLAGS_STRIP="-fstack-protector-string"
dpkg-buildpackage -rfakeroot
You can also make both ways persistent via configuration files.
I'm trying to compile gcc5.3.0 on my Raspberry Pi with latest Raspbian system image.
$ ./configure --enbale-checking=release --enable-languages=c,c++,fortran --host=arm-cortexa7_neon-linux-gnueabihf --build=arm-cortexa7_neon-linux-gnueabihf --target=arm-cortexa7_neon-linux-gnueabihf
$ make
However, the original compiler (gcc4.9) complains about not founding sys/cdefs.h when compiling libgcc.
I checked I have libc6-dev and build-essential installed.
So I used grep -R 'cdefs' /usr/include/ to search it and I found it at /usr/include/bsd/. I created the sys directory and made hard links to these headers under /usr/include/bsd/sys.
This time it gave me a more weird error,
/usr/include/stdio.h:312:8: error: unknown type name 'FILE'.
I searched this on stackoverflow, and there's a similar question, https://stackoverflow.com/a/21047237/5691005. But when I removed /usr/include/sys and /usr/include/bsd, then reinstalled libc6-dev, I cannot find sys/cdefs.h under /usr/include, and the compiler gave errors still.
I'm now totally lost. Any suggestion will be appreciated.
I had similar problem with compiling gcc-8.2. I tried to do as described here with reinstalling:
sudo apt-get --reinstall install libc6 libc6-dev
After that I was locating all missing headers:
find / -name cdefs.h
and copying them to /usr/include:
those steps allowed only to move forward but I still didn't manage to completely build gcc.
The best solution I found is to download compiled version of gcc-8.1 from:
https://solarianprogrammer.com/2017/12/07/raspberry-pi-raspbian-compiling-gcc/
I also ran into this problem when creating a containerized build environment for cross-compiled Qt applications for raspberry pi 4.
I found I needed to edit the mkspec for the linux-rasp-pi4-v3d device and add another cflag so that gcc could find the header from my Raspi sysroot that was used to cross-compile Qt.
Specifically under qtbase/mkspecs/devices/linux-rasp-pi4-v3d-g++/qmake.conf:
QMAKE_CFLAGS = -march=armv8-a -mtune=cortex-a72 -mfpu=crypto-neon-fp-armv8 -I$$[QT_SYSROOT]/usr/include/arm-linux-gnueabihf
I'm trying to link DLL with the following command:
g++ -DFTCSPI_EXPORTS -shared -fpic -static-libgcc -static-libstdc++ tmp\*.o "%D2XX_Dir%\ftcspi.lib" "%TclLibFile%" -o tmp\ftcspiif.dll
I'm getting this error: g++: unrecognized option '-static-libstdc++'
I've checked I have libstdc++-6.dll in C:\MinGW\bin and my gcc version is 4.4.7.
Does anyone have any ideas what might be going on? Thanks in advance.
my gcc version is 4.4.7.
The -static-libstdc++ option was added in 2009 in this patch. The first released GCC version with this flag is 4.5.
As Employed Russian stated, the -static-libstdc++ flag was added to GCC as of version 4.5.
Based on your comment to his answer though, if you're having trouble with installing/reinstalling/upgrading MinGW, I Highly suggest checking out http://tdm-gcc.tdragon.net/ as they provide an up-to-date installer for the MinGW environment in both 32 & 64 bit flavors.
They also apply various patches to the environment but you can choose different versions of various packages to install if you have specific requirements or just want to stick with the vanilla MinGW environment.
I'm trying to install apache from source on my mac. But keep running into problems. I've tried a ton of different things and just can't get this to build.
First, I couldn't configure without errors so I reinstalled apache apr. Now, I can configure but when I run make, I get this error:
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
I tried this to add in the libtool tag:
./configure LIBTOOL='/usr/local/bin/glibtool --tag=CC'
And this still gave the same error. I read that mountain lions glibtool is the unix-like libtool so that's why I tried this here. Still to no avail. I also tried symlinking the libtool that make uses to other versions on my machine, still to no avail, as I got the same error.
Here's what the make command runs, I tried symlinking /usr/share/apr-1/build-1/libtool
/usr/share/apr-1/build-1/libtool --silent --mode=compile /usr/local/Cellar/apple-gcc42/4.2.1-5666.3/bin/gcc-4.2 -std=gnu99 -O2 -arch x86_64 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -I/opt/local/include -I/opt/X11/include -I. -I/usr/local/src/httpd-2.4.3/os/unix -I/usr/local/src/httpd-2.4.3/include -I/usr/include/apr-1 -I/usr/local/include -I/usr/local/src/httpd-2.4.3/modules/aaa -I/usr/local/src/httpd-2.4.3/modules/cache -I/usr/local/src/httpd-2.4.3/modules/core -I/usr/local/src/httpd-2.4.3/modules/database -I/usr/local/src/httpd-2.4.3/modules/filters -I/usr/local/src/httpd-2.4.3/modules/ldap -I/usr/local/src/httpd-2.4.3/modules/loggers -I/usr/local/src/httpd-2.4.3/modules/lua -I/usr/local/src/httpd-2.4.3/modules/proxy -I/usr/local/src/httpd-2.4.3/modules/session -I/usr/local/src/httpd-2.4.3/modules/ssl -I/usr/local/src/httpd-2.4.3/modules/test -I/usr/local/src/httpd-2.4.3/server -I/usr/local/src/httpd-2.4.3/modules/arch/unix -I/usr/local/src/httpd-2.4.3/modules/dav/main -I/usr/local/src/httpd-2.4.3/modules/generators -I/usr/local/src/httpd-2.4.3/modules/mappers -prefer-non-pic -static -c exports.c && touch exports.lo
This still didn't work.
Finally, I got further if I ran configure like this, ./configure --with-apr='/usr/local/src/apr/apr-config (where I installed the system, but this is still broken.) This got me further but it still wouldn't finish make, and gave me a ton of errors like this.
exports.c:1809: error: redefinition of 'ap_hack_apr_version_string'
exports.c:1141: error: previous definition of 'ap_hack_apr_version_string' was here
I finally figured it out ...
For anyone having trouble installing apache on Mountain Lion, it looks like the default LIBTOOLS in the source's build/config_vars.mk file is the wrong location.
I reinstalled LIBTOOLS with homebrew (which put it at /usr/local/bin/glibtool) and set this as the variable and all worked fine.
I was just starting to study obj-c on Ubuntu Linux today, the tutorial that I followed is http://www.otierney.net/objective-c.html, when I typed in the code that requires for Foundation/NSObject.h, the error appeared:
Fraction.h:1: fatal error: Foundation/NSObject.h: No such file or directory
and i searched for the solutions, and found a proper one
gcc -o Fraction -I/usr/GNUstep/System/Library/Headers
-L/usr/GNUstep/System/Library/Libraries
Fraction.m
-ldl
-lobjc
I tried this, but I found that I cannot find Headers under the Library directory. (My folder of GNUstep is /usr/share/GNUstep).
Does anyone know how to achieve the Headers?
I installed all the dev packages related to GNUstep but still no luck.
Hope I state my question clear enough. Sorry for my English.
Try with gnustep-config
gcc `gnustep-config --objc-flags` \
`gnustep-config --objc-libs` Fraction.m -o Fraction
GNUStep uses a fairly involved set of gmake macros - I wouldn't expect a simple command-line invocation of gcc to work very well, although to be honest I haven't tried that way myself. I found Nicolo Pera's tutorial and the project's own reference page to be quite useful when learning how to write make files for use with GNUStep.
In my case, compiling SOPE on CentOS 7, installed
yum install gnustep-base-devel
This solved the problem.
In my case, I installed gnustep-base to fix this error:
yum install gnustep-base