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.
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 am trying to build MKL-accelerated version of TensorFlow using bazel 0.5.1, gcc 6.2, binutils 2.28, Anaconda2 python on Scientific Linux 7.2.
Apparently the system /lib64/libstdc++.so.6 is too old, so I am trying to use gcc installed in another directory. PATH, LD_LIBRARY_PATH are modified to prepend the corresponding paths (using modules). However, while bazel has no trouble picking up correctly executables for gcc, ld, python, it still tries to load old system /lib64/libstdc++.so.6. How to force it to use the one from gcc 6.2? Why does not it pick it up from LD_LIBRARY_PATH?
According to google many people are having trouble with this but I could not find a solution that would work for me. I had no trouble building TensorFlow under Ubuntu 16.04 that has sufficiently new gcc in the standard location.
I do:
1) ./configure
The only non-default options I choose is use MKL and download MKL
2) bazel build --config=mkl --copt="-DEIGEN_USE_VML" -s -c opt //tensorflow/tools/pip_package:build_pip_package
.....
example/example_parser_configuration.proto tensorflow/core/protobuf/control_flow.proto tensorflow/core/protobuf/meta_graph.proto tensorflow/core/protobuf/named_tensor.proto tensorflow/core/protobuf/saved_model.proto tensorflow/core/protobuf/tensorflow_server.proto tensorflow/core/util/event.proto tensorflow/core/util/test_log.proto)
ERROR: /scratch/midway2/ivy2/TF_intel/tensorflow/tensorflow/tools/tfprof/BUILD:42:1: null failed: protoc failed: error executing command bazel-out/host/bin/external/protobuf/protoc '--python_out=bazel-out/local-opt/genfiles/' -I. -I. -Iexternal/protobuf/python -Ibazel-out/local-opt/genfiles/external/protobuf/python ... (remaining 5 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by bazel-out/host/bin/external/protobuf/protoc)
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6: versionCXXABI_1.3.8' not found (required by bazel-out/host/bin/external/protobuf/protoc)
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bazel-out/host/bin/external/protobuf/protoc)
.....
Thank you,
Igor
sorry for the slow reply. Bazel by design ignores LD_LIBRARY_PATH when running actions. It doesn't have to ignore them during C++ toolchain detection, but at the moment, it does :/ To help you forward, I would try adding --sysroot= as linkopt or using bazel grte_top flag. Depending on where your libstdc++.so lives, you might need to disable sandbox. The principled solution would be to write a custom CROSSTOOL that specifies builtin_sysroot or grte_top. But that is not an easy task.
Let me know if I lost you somewhere in that paragraph :)
I am trying to build SLitrani on Ubuntu 12.04 64-bit. I have already built ROOT 5.34.03 from source and I did figure out how to set the LD_LIBRARY_PATH and PATH variables for $ROOTDEV so the problem is not there but when I try to make SplineFit I get
>>> g++: error: unrecognized option ‘-soname=libSplineFit.so’
make: *** [libSplineFit.so] Error 1
I also did change all the -m32 to -m64 in the Makefiles so I don't know what is going on. I was able to get TwoPad installed but I can't continue from SplineFit. I have been on this build for quite some time and would appreciate any help.
From memory, soname is a linker operation, not a compiler one. So, if you're doing it with g++, you may need to change the option into something like:
-Wl,-soname=libSplineFit.so
The following transcript shows that this is necessary:
pax> g++ --soname=x -Wall -o qq qq.cpp
cc1plus: error: unrecognized command line option "-fsoname=x"
pax> g++ -Wl,-soname=x -Wall -o qq qq.cpp
pax>
From the online GNU docs for gcc:
-Wl,option: pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas.
I know this is an old question but after a week of struggling I thought I should post my findings.
I've successfully edited the makefiles for this so they can compile on Ubuntu 12.04 x64.
You can remove the -soname option completely, it seemingly is unnecessary.
As mentioned: all "m32" change to "m64".
You can replace "$ROOTSYS/libs" with "$ROOTLIBS"
and with TwoPad makefile reorder the library order (under LIBS += (.....)) so that -lTwoPad is NOT last on the list, and for VisuSLitrani make -lPhysMore last in its group.
As far as I know the errors saying "set but not used" can be ignored.
If any of this still doesn't work contact me back and I can send you my makefiles.
Here a nice explanation of the -soname linker option, how to call it and what it is good for.
Summary
You can simply use gcc -shared -Wl,-soname,libfoo_v1.so -o libfoo_v1.so libfoo_v1.o and skip the following discussion ;)
call it as gcc -shared -Wl,-soname,libfoo.so -o libfoo_v1.so libfoo_v1.o
after compiling you need to create an symbolic link pointing to libfoo_v1.so ln -s libfoo_v1.so libfoo.so before you can execute your code.
This is used to link against different shared libraries during compiletime and runtime. Obviously these libraries need a similar interface. You can use this for managing different versions.
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
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.