In my makefile I have:
g++ -o Out Out.o -I Headers_Directory -L Libraries_Directory -lFile1 -lFile2
In my Libraries_Directory I have two files libFile1.a and libFile2.so
ld finds libFile1.a but cannot find libFile2.so. How that is possible and how can I resolve the issue?
I am compiling in Cygwin and using GNU gcc-g++ compiler.
A minimalist that regenerates the error:
Download the Linux Version of Gurobi here. Then, install the software using this instruction. You need to activate the software by obtaining a license from here. Free academic license for research purpose is available. Finally navigate to the following folder
installation_directory/gurobi701/linux64/examples/build
and issue the command make. You have to compile on Cygwin with GNU gcc-g++ compiler.
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 a newbie to Objective C programs. I'm learning to code from tutorialspoint.com
As mentioned therein I downloaded GNUstep (Windows).
First, installed the MSYS/MinGW System package and then core package.
After that followed the steps mentioned there. I created a simple program with name hello.m and Stored that in C drive (Snapshot 1)
I don't know the meaning of this command below but entered it:
$ gcc gnustep-config --objc-flags -L /GNUstep/System/Library/Libraries hello.m -o hello -lgnustep-base -lobjc
The error it shows is - sh: gcc: command not found
Please help with the same, to compile and run my first Objective C program
gcc is the compiler, the other parameters are for compiling objective-c code.
Apparently you have misconfiguration in MSYS/MinGW setup.
Check out following post which has alternative and easier solution for running gcc under Windows.
I want to generate a dll file in MinGW, I have several object dependencies in order to do that, one of my object dependencies is libdl.so, I add this object in unix simply as :
g++ xx.o yy.o /usr/lib/libdl.so -o module.so
but in MinGW, I don't have any idea how to add this object. any ideas?
There is a MinGW port of libdl that you can use just like under Unix. Quote from the website:
This library implements a wrapper for dlfcn, as specified in POSIX and SUS, around the dynamic link library functions found in the Windows API.
It requires MinGW to build.
You may get pre-built binaries (with MinGW gcc 3.4.5) and a bundled source code from the Downloads section.
The following commands build and install it in a standard MinGW installation (to be run from your MinGW shell):
./configure --prefix=/ --libdir=/lib --incdir=/include && make && make install
To compile your library as a DLL, use the following command:
g++ -shared xx.o yy.o -ldl -o module.dll
I encountered the same problem (msys2, 32bit version of compiler etc.).
For me I found out that the libdl.a was available in /usr/lib but not in /mingw32/lib. I was able to solve the problem by linking it to the /mingw32/lib folder:
ln -s /usr/lib/libdl.a /mingw32/lib
When I try to compile a simple c++ file using Magick++ and cygwin, I keep getting this result:
$ g++ -o imageTest imageTest.cpp `GraphicsMagick++-config --cppflags --cxxflags --ldflags --libs`
g++: unrecognized option `-no-undefined'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -ldpstk
collect2: ld returned 1 exit status
I installed ImageMagick through the cygwin gui setup.
GraphicsMagick and ImageMagick are two different libraries. If you want to build your program using ImageMagick, as you state, it's just a matter of changing
GraphicsMagick++-config
into
Magick++-config
This should work. As for GraphicsMagick, it looks like the current -devel library in Cygwin is broken, as it requires a library (libdpstk) which is no longer available. (Have a look here if you are interested.)