Building Debian/Ubuntu packages with old gcc: CFLAG adjustment? - objective-c

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.

Related

building TensorFlow: bazel cannot find libstdc++ in non-standard directory

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 :)

Linker only sees a portion of libraries in a directory

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.

g++: unrecognized option '-static-libstdc++'

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.

Building Apache on Mountain Lion libtool problems

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.

Cant find Foundation/NSObject.h in Linux while build Obj-c Program

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