-- Question solved --
This question is solved. Thanks for all the help!
The problem and the reason is briefly stated as following for other readers in the future:
[Environment]
Ubuntu 14.04, Bazel, C++
[Question]
I want to include an external library. So I download the source file and make it as as a static lib .a.
I correctly set the BUILD, WORKSPACE and related files. However, when compile, it alerts the error:
Linking of rule '//main' failed (Exit 1)
main: error: undefined reference to 'void ex_lib::compute(double*, double const*, double const*)'
collect2: error: ld returned 1 exit status
I tried with the .lo and alwayslink method here but doesn't work.
Alternate to "`--whole-archive`" in bazel
[Reason]
It is because that the external library source files contains duplicate header files. So I fix the header file problem. Make the .a again. Then everything works.
So nothing wrong with the bazel. It is the library itself that cause the problem. But the error information is confusing and I think it is caused by bazel.
What you can do to investigate further is to run the clean bazel build with --subcommands to see individual command lines of actions executed. Then you can cd into the sandbox, and execute the same gcc command as bazel does and debug what's wrong. Or you can try to get linking to work by handwriting gcc command, and pasting here both the command bazel generated, and your desired command. Is it possible that you have multiple liegroups libs installed on the system and gcc is getting one that's incompatible with headers you're including?
The problem is solved. Special thanks to mhlopko.
It is mainly because there is errors with the lib source file. Thus .a file I use contains errors. Now the bazel works fine with the new lib file.
By the way, now bazel works fine with both .a or .so file that I generated.
Related
I've been trying unsuccessfully for a week to get a build of Assimp that is linkable with a project I'm compiling with MinGW.
It seems that the makefiles that cmake generates to build Assimp 4.1.0 are flawed somehow because when I try to use them I get some warnings which ultimately lead to a failure when trying to link "libassimp.dll"
CMakeFiles\assimp.dir/objects.a(Exporter.cpp.obj):Exporter.cpp:(.text+0x1571): undefined reference to `Assimp::ExportScene3MF(char const*, Assimp::IOSystem*, aiScene const*, Assimp::ExportProperties const*)'
collect2.exe: error: ld returned 1 exit status
code\CMakeFiles\assimp.dir\build.make:3159: recipe for target 'code/libassimp.dll' failed
mingw32-make[2]: *** [code/libassimp.dll] Error 1
CMakeFiles\Makefile2:289: recipe for target 'code/CMakeFiles/assimp.dir/all' failed
mingw32-make[1]: *** [code/CMakeFiles/assimp.dir/all] Error 2
Makefile:131: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
Before it gets to this the only error it seems is a format error in certain header files which use the %llu conversion type when referencing the ai_snprintf function.
warning: unknown conversion type character 'l' in format [-Wformat=]
warning: too many arguments for format [-Wformat-extra-args]
I'm using the latest MinGW which has g++ version 6.3.0, by default using the c++14 standard. I did a test to see if this standard on windows didn't support %llu but when I wrote a CMakeLists.txt file, generated a makefile, and compiled using the makefile, it gave no errors and ran as expected.
I've tried using cmake to generate a Visual Studio 2017 project and building it there and it links fine when used in Visual Studio. If I call the same functions and compile with MinGW it doesn't link, I guess this is just an interoperability problem, but it suggests I have everything assimp needs to be built properly.
My thoughts are, somehow assimp's cmake modules are defining what standard assimp should be compiled with, and that standard doesn't support %llu, but that sounds silly. I don't like to assume something is a bug but these warnings don't seem like they're thrown because I forgot to do something.
I've tried editing the makefile it gives me and adding to the front:
CXX = g++
CXXFLAGS = -Wall -std=c++11 $(DEBUG)
Cause somewhere it said that could work, but it didn't change anything.
I also tried defining the macro __USE_MINGW_ANSI_STDIO 1 for cmake but that didn't do anything either.
But I really don't know much about building binaries (though I've learned more than I expected to recently), so any advice, information, guidance is appreciated.
I am trying to build a program that relies on wxWidgets to run properly. I have the latest version of Xcode installed. I have tried building wxWidgets (both wxWidgets-3.0.2 and wxWidgets-2.9.4, the version originally used by the main program). However, in both cases, running the makefile for the main program gives the following error:
make: /Users/path to wxWidgets/wxWidgets-2.9.4/build-cocoa-release/utils/wxrc/wxrc: No such file or directory
As I understand it, I need to build wxrc to get my main program to build properly (I have tried this, but apparently some header files are missing). Is there any way to configure wxWidgets before this step that will automatically build wxrc as well? Or is that something I need to build separately? If it is separate, how would that be done?
I've pasted the code I originally used to configure wxWidgets below, with line breaks to make it easier to read:
../configure --with-osx_cocoa --with-macosx-version-min=10.7
--with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
--prefix="$(pwd)" --with-opengl CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -std=c++11"
OBJCXXFLAGS="-stdlib=libc++ -std=c++11" LDFLAGS=-stdlib=libc++
There is one error while building wxWidgets:
../src/osx/cocoa/utils.mm:250:28: error: cannot initialize a parameter of type 'id' with an lvalue of type
'wxNSAppController *'
[NSApp setDelegate:appcontroller];
When I go into the samples directory and enter "make", I get: ld: library not found for -lwx_osx_cocoau_xrc-2.9 clang: error: linker command failed with exit code 1 (use -v to see invocation) When entering "make" in demos, I get: ld: library not found for -lwx_osx_cocoau_core-2.9 clang: error: linker command failed with exit code 1 (use -v to see invocation)
If I missed any steps I should have taken before these (something with Xcode maybe?) please let me know. Thank you very much in advance.
Similar question. I have sugested a workaround proposed on a forum as follows: you can use --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/".
I have a question very simliar to Cross compiler default include path setup but there wasn't the answer I was looking for.
I built a cross-compiler for openrisc. I have it in ~/openrisck/toolchain/
under there, I have bin(or32-linux-* excutables are here), include, lib, lib64, libexec, or32-linux, share.
under or32-linux, I have bin, include, lib, sys-root.
When I build busybox, I gave CONFIG_CROSS_COMPILER_PREFIX as "or32-linux-".
and CONFIG_SYSROOT as "$SYSROOT" which is ~/openrisk/toolchain/or32-linux/sys-root.
then I run 'make install' in buxybox source. Since the path includes the cross-compiler directory, it compiles for or32-linux-. But I have an error below
ckim : srctree = /home/ckim/openrisc/busybox
CC applets/applets.o
In file included from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/syslimits.h:7:0,
from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:34,
from include/platform.h:141,
from include/libbb.h:13,
from include/busybox.h:8,
from applets/applets.c:9:
/home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:169:61: fatal error: limits.h: No such file or directory
compilation terminated.
make[1]: *** [applets/applets.o] Error 1
make: *** [applets_dir] Error 2
which makes me thinks that Ah! the cross-compiler uses the include path relative to the executable. (see above bin/../lib/gcc/or32-linux/version/include-fixed)
So the include limits.h goes to the gcc's limits.h correctly. The last file syslimits.h has #include_next when the limits.h file have already been included. and the compiler complains that the file cannot be found.
Can somebody tell me how to solve this problem? (limits.h includes syslimits.h and syslimits.h includes limits.h .. )
EDIT : I ran 'make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install'
then I got 'lutimes undeclared in coreutil/touch.c' error. Assuming the limit.h problem is gone, this means I should give these command line arguments because CROSS_COMPILE for make is different from CONFIG_CROSS_COMPILER_PREFIX in busybox configuration and make's CONFIG_PREFIX is different from CONFIG_SYSROOT for busybox configuration. so to remove the lutimes error, I ran 'make menuconfig' and removed CONFIG_TOUCH. Then I reran the make(make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install), and this time got
procps/free.c: In function 'free_main':
procps/free.c:51:17: error: storage size of 'info' isn't known
procps/free.c:77:2: warning: implicit declaration of function 'sysinfo'
I found that in $SYSROOT/usr/include/sys/sysinfo.h, struct sysinfo is defined. I don't know why it says it's not defined. Any help would be deeply appreciated. Thanks!
For anyone who might be facing the same problem I had..
I tried about 3 times with the old toolchain but failed.
Yesterday, I got help from IRC (openrisc) and someone told me there is an updated toolchain for or1k. (not or32 which is old. I should have read the opencore page first..)
The page is
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29 (read from Linux (uClibc) toolchain (or1k-linux-uclibc))
While building glibc, I get this error.
*glibc/build/elf/dl-allobjs.os: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status*
What is an .os file and what binutil do I need to install to fix this?
What is an .os file
It's just an object file, intended to be linked into a shared library. UNIX linkers for the most part don't care about file extension, you can call file foo.o, foo.oS, or just about anything else, it would still work.
what binutil do I need to install to fix this?
It's unlikely that your problem has anything to do with binutils. It is more likely that the file got corrupted somehow.
What does file glibc/build/elf/dl-allobjs.os report? Are you cross-compiling? Does the problem reproduce if you reconfigure and rebuild in a different directory?
When compiling GCC it is possible to get very far in the build process only to hiccup on an error complaining about the lack of gperf installed. After installing gperf and running, I hit an "undefined reference to libc_name_p." I've looked at the solutions here and here but they weren't helpful.
When gperf wasn't installed, the compilation script ran the command anyway but generated a blank ./gcc/cp/cfns.h. Since this file was newer than the source (./gcc/cp/cfns.gperf) the makefile left it alone and never regenerated the 'real' file when you actually had gperf. To continue, run rm ./gcc/cp/cfns.h and try again.