Crypto++ linker error using ANT - ant

I am trying to reverse engineer a previous employee's build process for some custom software he wrote for us. I've seen to get everything to compile okay, but I get an error in the linking process that points to a problem with crypto++. Any clues?
compile.util:
compile:
[echo] Compiling: util
[cc] Starting dependency analysis for 55 files.
[cc] 55 files are up to date.
[cc] 0 files to be recompiled from dependency analysis.
[cc] 0 total files to be compiled.
link.util:
link:
[echo] Linking shared library: libutil
[cc] 0 total files to be compiled.
[cc] Starting link
[cc] /usr/bin/ld: /home/john/softwarename/thirdparty/crypto/5.6.1_64/libcryptopp.a(cryptlib.o): relocation R_X86_64_32 against `CryptoPP::DEFAULT_CHANNEL' can not be used when making a shared object; recompile with -fPIC
[cc] /home/john/softwarename/thirdparty/crypto/5.6.1_64/libcryptopp.a: could not read symbols: Bad value
[cc] collect2: ld returned 1 exit status
BUILD FAILED
/home/john/softwarename/build/build.xml:167: Following error occured while executing this line
/home/john/softwarename/build/link.xml:27: gcc failed with return code 1
Os is Fedora 11

Every object file you link into a shared library must be position independent, meaning the loader can move it wherever it wants in memory and it will still work. Your crypto library was not compiled that way, hence the admonition to recompile it with -fPIC added to your compile flags. Alternately, you can make libutil a static library instead of a shared one. Without more details on your build files, I can't provide more details on how to do that or which one to choose.

Related

Trouble building Drake with Bazel

I have been attempting to build Drake from source with Bazel on Ubuntu 18.04 but the following error occurs when I run
bazel build ...
from the Drake root directory:
ERROR: /home/username/dir/drake/bindings/pydrake/BUILD.bazel:56:37: Action bindings/pydrake/documentation_pybind.h failed (Exit 1) mkdoc failed: error executing command bazel-out/host/bin/tools/workspace/pybind11/mkdoc -DDRAKE_COMMON_SYMBOLIC_DETAIL_HEADER -DEIGEN_MPL2_ONLY -DHAVE_CSTDDEF '-DFMT_HEADER_ONLY=1' '-DFMT_NO_FMT_STRING_ALIAS=1' -DHAVE_SPDLOG ... (remaining 1096 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
external/eigen/include/_usr_include_eigen3/Eigen/Core:66:12: fatal error: 'new' file not found
Traceback (most recent call last):
File "/home/username/.cache/bazel/_bazel_username/6e98757561df7a931d098ab985a3e673/sandbox/linux-sandbox/1371/execroot/drake/bazel-out/host/bin/tools/workspace/pybind11/mkdoc.runfiles/drake/tools/workspace/pybind11/mkdoc.py", line 841, in <module>
main()
File "/home/username/.cache/bazel/_bazel_username/6e98757561df7a931d098ab985a3e673/sandbox/linux-sandbox/1371/execroot/drake/bazel-out/host/bin/tools/workspace/pybind11/mkdoc.runfiles/drake/tools/workspace/pybind11/mkdoc.py", line 805, in main
severities.count(cindex.Diagnostic.Fatal)))
RuntimeError: Parsing headers using the clang library failed with 0 error(s) and 1 fatal error(s)
----------------
Note: The failure of target //tools/workspace/pybind11:mkdoc (with exit code 1) may have been caused by the fact that it is running under Python 3 instead of Python 2. Examine the error to determine if that appears to be the problem. Since this target is built in the host configuration, the only way to change its version is to set --host_force_python=PY2, which affects the entire build.
If this error started occurring in Bazel 0.27 and later, it may be because the Python toolchain now enforces that targets analyzed as PY2 and PY3 run under a Python 2 and Python 3 interpreter, respectively. See https://github.com/bazelbuild/bazel/issues/7899 for more information.
----------------
INFO: Elapsed time: 2345.311s, Critical Path: 321.76s
INFO: 1378 processes: 1378 linux-sandbox.
FAILED: Build did NOT complete successfully
Prior to building, I ran:
sudo ./setup/ubuntu/install_prereqs.sh
as mentioned in the installation instructions.
I had also set the environment variables for the c and c++ compilers to $CC=/usr/bin/gcc and $CXX=/usr/bin/gcc because I was suspicious of compiler issues being the problem. To compare against this, I also tried to build with $CC=/usr/bin/clang-9 and $CXX=/usr/bin/clang++-9, with a different resulting error:
ERROR: /home/username/dir/drake/systems/framework/BUILD.bazel:213:17: C++ compilation of rule '//systems/framework:cache_and_dependency_tracker' failed (Exit 1) clang-9 failed: error executing command /usr/bin/clang-9 -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 77 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
In file included from systems/framework/cache.cc:1:
bazel-out/k8-opt/bin/systems/framework/_virtual_includes/cache_and_dependency_tracker/drake/systems/framework/cache.h:7:10: fatal error: 'cstdint' file not found
#include <cstdint>
^~~~~~~~~
I suspect that there is some issue with the include paths that are being used during build since both compilers were unable to find standard files, however I am unsure of what to try next or how to fix this. Any suggestions or advice would be greatly appreciated!
This seems to be the same problem that I encountered. My Question is here Encounter "RuntimeError: The operating system's C++ standard library is not installed correctly" when build drake from source using bazel and I solve my problem following #jwnimmer-tri's answer.
It turns out that Clang is looking for GCC's standard library and it seems that it looks for GCC with higher version (not sure). I guess the problem is that you have gcc-8 installed but not g++-8, so after you install g++-8 you can fix the issue. Another possible way to solve your problem is to follow #jwnimmer-tri's answer in my question to remove gcc-8 completely.

Library not found for -llib. (clang: error: linker command failed with exit code 1 (use -v to see invocation))

I am working on a project that was previously done and uploaded on app store.When I run this app in Xcode 5.0 it is working fine but when I run this on Xcode Version 5.1.1 (5B1008) I am getting Linker error on both device and simulator.
Error Message- Library not found for -llib. (clang: error: linker command failed with exit code 1 (use -v to see invocation)).
I have searched a lot but I didn't get any thread about Library not found for -llib error. Is there anything I have to change in build settings to resolve this?
Look at the linker command line in detail for the -L options being used:
Then use Terminal or Finder to see if your libXXX.a file exists in those directories. If the library exists elsewhere then you need to configure your Library Search Paths:
However there several details which you have not provided in your question when using a library within an app:
Is the library built as part of the Xcode project/workspace (as in the first image)?
Is the library supplied by a third-party with binary (.a) and header files (as in the second image)?
TL;DR: I ran make in the wrong directory so the paths were messed up.
Problem:
>make
linking ../build/release/yubikey-personalization-gui
/usr/x86_64-suse-linux/bin/ld: cannot find -llib
...
I ran into this when compiling the Yubikey Personalisation Tool. I tracked down the -llib call in my Makefile which looked like this:
...
LINK = #echo linking $# && g++
...
LIBS = $(SUBLIBS) -L/usr/lib64 -L../lib/release -llib -lyubikey -lykpers-1 -lQtGui -L/usr/lib64 -L/usr/X11R6/lib -lQtCore -lpthread
...
$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)
So it was setting a variable called LINK which would print "linking" and then call g++, which is the compiler.
Then it set the var LIBS which would hold the ominous -llib.
Then it composes and runs the command $(LINK) ... $(LIBS).
Which runs g++ with the parameter -llib.
And what does that do? Turns out -l<something> is telling the compiler to use the something-library. So it asks for the library called lib here. Which is strangely generic. I figured out that the sources came with a directory called lib/, which was at ../lib.
So starting make from a directory higher up fixed it.
You should remove libstdc++ from other linker flags in your xcode project
https://stackoverflow.com/a/53103383/1344237

Marmalade iOS multiple architectures support

The instruction for building marmalade extension static lib-wrappers from the official site shows how to build only single architecture (armv6) extension. I tried to include many architectures into the project:
if {{defined I3D_OS_IPHONE}}
{
includepath incoming
files
{
["MyTracker Library armv7"]
(incoming/armv7)
"*.o"
["MyTracker Library armv7s"]
(incoming/armv7s)
"*.o"
["MyTracker Library armv64"]
(incoming/armv64)
"*.o"
["source"]
(use_first_found, source/iphone, source/generic)
MyTracker_platform.mm
#Add any iphone-specific files here
}
}
But I got many error messages after trying to build it:
Executing: '/usr/local/bin/scons -Q compiler=clang'
scons: warning: Support for pre-2.7.0 Python version (2.6.8) is deprecated.
If this will cause hardship, contact dev#scons.tigris.org.
File "/usr/local/bin/scons", line 192, in <module>
Librarian [ar] /Users/misha/Documents/MyTracker/lib/iphone/libMyTracker.a
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ranlib: archive member: /Users/misha/Documents/MyTracker/lib/iphone/libMyTracker.a(MyDispatcher.o) cputype (7) does not match previous archive members cputype (12) (all members must match)
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ranlib: archive member: /Users/misha/Documents/MyTracker/lib/iphone/libMyTracker.a(MyTracker.o) cputype (16777223) does not match previous archive members cputype (12) (all members must match)
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ranlib: archive member: /Users/misha/Documents/MyTracker/lib/iphone/libMyTracker.a(MyNetwork.o) cputype (16777228) does not match previous archive members cputype (12) (all members must match)
....
malformed object (unknown load command 1)
ar: internal ranlib command failed
scons: *** [/Users/misha/Documents/MyTracker/lib/iphone/libMyTracker.a] Error 1
Executing 'scons -Q' failed. (return code 2). Retry
error: Executing 'scons -Q' failed. (return code 2)
FAILED (error code=3)
How to build an extension with multiple architectures support?
This is typically not the advised way to handle this. You look like you're trying to bring in symbols from those libs, something that the EDK does not support. Your best option is to include these libs (or most probably, just the arm6/7 lib, depending on how low you want to take it) at deploy time along with the compiled extension and instead, compile the extension using a header file (either supplied by the developer of any SDK you're using, or one you've written to compile those .o libs).
Building for multiple targets is something that is being refactored. My understanding is that at some stage both the documentation and the underlying code has got stale. I believe the approach will be quite different from what you are trying to do - I'm not sure why you are pulling in .o files but generally that does work too well in marmalade.

c++ in MonoDevelop: clang: error: no input files

I have a question that is probably trivial, but I can't see the solution now. I have a .cpp file that I would like to run through MonoDevelop. Unfortunately, instead of a small Bantumi simulation, I only get:
Building Solution: Bantumi (Debug)
Building: Bantumi (Debug)
Performing main compilation...
Precompiling headers
Compiling source to object files
Generating binary "Bantumi" from object files
g++ -o "/Users/myname/Projects/Bantumi/Bantumi/bin/Debug/Bantumi"
clang: error: no input files
Build complete -- 1 error, 0 warnings
---------------------- Done ----------------------
Build: 1 error, 0 warnings
From what I found, most people had this problem when there was no such file in the current directory, or the compiler did not have a valid address. However, my file is exactly where the compiler looks for it, but it still produces an error. Do you know what else could lead to this error message?
Thanks a lot! If this type of question has already been solved, you can just send me a link to it.

fail to build Opencv in windows using code:block

Following this link. I am stuck in the last two steps during setting up my workstation.
As a compiler I use Code:Block MinGW; I have already generated the compiled opencv files, now I need to build the sln file in Windows. I use Code Block to build this OpenCV Project File in the path D:\OpenCV\Build\Opencv, where I put the generated bin file after using Cmake.
During the building, it stopped at 40%, saying;
Linking CXX executable ....\bin\opencv_perf_core.exe
c:/codeblock/codeblocks/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/bin/ld.exe:
warning: auto-importing has been activated without
--enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from
auto-imported DLLs. Cannot export _ZN12_GLOBAL__N_13ROp3allEv: symbol
not found Cannot export _ZN12_GLOBAL__N_17CmpType3allEv: symbol not
found collect2: ld returned 1 exit status mingw32-make.exe[2]: *
[bin/opencv_perf_core.exe] Error 1 mingw32-make.exe1: *
[modules/core/CMakeFiles/opencv_perf_core.dir/all] Error 2
mingw32-make.exe: * [all] Error 2 Info: resolving vtable for
cv::_OutputArray by linking to imp_ZTVN2cv12_OutputArrayE
(auto-import) Info: resolving vtable for cv::_InputArray by linking to
imp_ZTVN2cv11_InputArrayE (auto-import) Info: resolving vtable for cv::Exception by linking to imp_ZTVN2cv9ExceptionE (auto-import)
Creating library file: ....\bin\libopencv_perf_core.dll.a Process
terminated with status 2 (14 minutes, 29 seconds) 0 errors, 3 warnings
How can I solve this problem?
Unfortunately, there's not much you can do, according to http://code.opencv.org/issues/2523.
You will have to use a recent version of MinGW. It builds fine using the latest MinGW shipping with GCC 4.7.2.
This issue seems to have been introduced in OpenCV 2.4.3 as it is said version 2.4.2 builds fine.

Resources