I can't get an external library link with the main program using premake. For instance I've simplified the problem to this example:
./_external/ext.cpp
#include "ext.h"
int foo()
{
return 4;
}
./_external/ext.h
#pragma once
int foo();
./main.cpp
#include "stdio.h"
#include "_external/ext.h"
int main()
{
printf("%d", foo());
return 0;
}
./premake4.lua
solution "Test"
configurations { "Release", "Debug" }
project "TestMain"
language "C++"
kind "ConsoleApp"
files "main.cpp"
links
{
"_external/libfoo.a"
}
I create the GNU makefiles under Cygwin environment:
$ ./premake4.exe gmake
Building configurations...
Running action 'gmake'...
Generating Makefile...
Generating TestMain.make...
Done.
and I get the following error when I make:
$ make
==== Building TestMain (release) ====
Linking TestMain
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lD:/test/_external/libfoo.a
collect2: ld returned 1 exit status
TestMain.make:93: recipe for target `TestMain.exe' failed
make[1]: *** [TestMain.exe] Error 1
Makefile:16: recipe for target `TestMain' failed
make: *** [TestMain] Error 2
The only workaround I found is to use "linkoptions" instead of "links" to get rid of the "-l" but for me it's more like a hack than a solution.
You are doing it right, but Premake is getting it wrong. There was a bug in Premake's makefile generator that prevented things from linking properly. It is now fixed in both the stable (will become version 4.4) and dev (will become 5.0) repositories.
Nice to get that fixed—hope it helps.
Related
package main
// #cgo CFLAGS: -I./lib
// #cgo LDFLAGS: -L./lib -lfifo
// #include "shmfifo.h"
import "C"
func main() {
fifo := C.shmfifo_init(13, 3, 64)
for i := 1; i <= 100; i++ {
C.shmfifo_put(fifo, 9)
}
}
enter image description here
that is my project structure, error msg blow:
$ go build pppp.go
# command-line-arguments
ld: library not found for -lfifo
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Ok the issue seems to be isolated to your linker is not finding the libfifo.dylib file. So hence the following error:
ld: library not found for -lfifo
I would recommend either:
Replacing the relative reference in the -L args with the special cgo variable $SRCDIR to more explicitly point to the location. More on that in the godocs.
You can also copy the directory structure and cgo args in the following cgo/dylib tutorial by copying the libfifo file (assuming it can also link to other dependencies without issue).
I tried to build the opencv Library on my Windows 10 PC.
I managed to generate everything from source with cmake. (Nothing red, no errors).
When I try to build everything with mingw (mingw32-make install)
It starts building and after a while I get the following error.
[ 76%] Building CXX object modules/python3/CMakeFiles/opencv_python3.dir/__/src2/cv2.cpp.obj
In file included from C:/Python34/include/Python.h:8:0,
from C:\OpenCV\opencv-master\modules\python\src2\cv2.cpp:6:
C:/Python34/include/pyconfig.h:440:5: warning: "_MSC_VER" is not defined [-Wundef]
#if _MSC_VER >= 1800
^~~~~~~~
In file included from C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/lib/gcc/x86_64-w64-mingw32/6.2.0/include/c++/math.h:36:0,
from C:/Python34/include/pyport.h:328,
from C:/Python34/include/Python.h:50,
from C:\OpenCV\opencv-master\modules\python\src2\cv2.cpp:6:
C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/lib/gcc/x86_64-w64-mingw32/6.2.0/include/c++/cmath:1133:11: error: '::hypot' has not been declared
using ::hypot;
^~~~~
modules\python3\CMakeFiles\opencv_python3.dir\build.make:179: recipe for target 'modules/python3/CMakeFiles/opencv_python3.dir/__/src2/cv2.cpp.obj' failed
mingw32-make[2]: *** [modules/python3/CMakeFiles/opencv_python3.dir/__/src2/cv2.cpp.obj] Error 1
CMakeFiles\Makefile2:7051: recipe for target 'modules/python3/CMakeFiles/opencv_python3.dir/all' failed
mingw32-make[1]: *** [modules/python3/CMakeFiles/opencv_python3.dir/all] Error 2
Makefile:159: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
I found the following "Error: '::hypot' has not been declared" in cmath while trying to embed Python
But could not figured it out.
Can Anyone hint me in the direction. Where are those includes in the case of building OpenCV?
Versions:
OpenCV 3.2.0,
CMake 3.4.1,
GNU Make 4.1
Any help qould be appreciated!
Go to the following file
C:\OpenCV\opencv-master\modules\python\src2\cv2.cpp
and see if
#include "Python.h"
comes before #include <cmath>.
In that case exchange the order, i.e. write
#include <cmath>
#include "Python.h"
so that cmath comes before Python.h.
Try to build and see if that solves at list the error that you reported.
Is it possible to install SystemC on XCode? If so, how would I do it? Do I just need to set up some libraries and point xCode at them? I've set up openGL on xcode before but, I can't similar looking libraries for SystemC.
I tried following the top voted instructions in the link suggested and got these errors on the make install command:
...
clang: warning: argument unused during compilation: '-pthread'
clang: warning: argument unused during compilation: '-pthread'
../../libtool: line 1096: cd: .libs/libsystemc.lax/libkernel.a: No such file or directory
make[3]: *** [libsystemc.la] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
I got the same error trying the other instructions.
In order to use SystemC with xCode, you have to build the library first. You can follow instructions #rmaddy suggested : how to use and install SystemC in terminal mac OS X?
I suppose you installed SystemC (result of make install) in /usr/local/systemc and so you have /usr/local/systemc/include containing SystemC headers and /usr/local/systemc/lib-macosx64 containing the library.
Create a new xCode project. File -> New -> Project. Choose OS X / Application and finally Command Line Tool for example. Add a product name (SystemCExample) and choose C++ language.
Select your target (SystemCExample) on the left panel and then be sure you selected your target in the top left list (and not the project). Select the area Build Settings and under Search Paths you will find Header Search Paths. Click on the "+" and add SystemC headers path (/usr/local/systemc/include).
Then, select the section Build Phases and either add the path manually or drag and drop the static (libsystemc.a) or dynamic version (libsystemc.dylib) of SystemC library you can find in /usr/local/systemc/lib-macosx64 in Link Binary with Libraries part.
Finally, just add a minimalist SystemC code and press the build and run button:
#include <systemc>
int sc_main(int argc, char *argv[]) {
std::cout << "Hello, World!\n";
sc_core::sc_start();
return 0;
}
When i try to build googletest (and googlemock) 1.8.0 i get an undefined reference to MakeAndRegisterTestInfo when i try to link with libgtest.a. It works fine with version 1.7.0 with the same cmake/make setup. I guess i could use 1.7.0 but then i need to download and build gmock separately.
CMakeFiles/unittest.dir/test/test_led.cpp.o: In function `__static_initialization_and_destruction_0(int, int)':
test_led.cpp:(.text+0x23d): undefined reference to `testing::internal::MakeAndRegisterTestInfo(char const*, char const*, char const*, char const*, void const*, void (*)(), void (*)(), testing::internal::TestFactoryBase*)'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/unittest] Error 1
make[1]: *** [CMakeFiles/unittest.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
Other symbols in the libgtest.a works perfectly fine (example ::testing::InitGoogleTest) but as soon as i try to add a test with the macro TEST_F i get this error.
This is my testcase setup:
#include "gtest/gtest.h"
namespace {
// The fixture for testing (used by TEST_F).
class Foo : public ::testing::Test {
protected:
Foo();
virtual ~Foo() {};
virtual void SetUp();
virtual void TearDown();
};
Foo::Foo() {
};
void Foo::SetUp()
{
};
void Foo::TearDown()
{
};
TEST_F(Foo, Init) {
};
} // namespace
int main(int argc, char **argv)
{
::testing::InitGoogleTest(&argc, argv);
int ret = RUN_ALL_TESTS();
return ret;
}
Cmake google test snippet:
It downloads from a local folder. It builds and i get a libgtest.a file.
### Unit test ###
# Google test
ExternalProject_Add(EXT_googletest
PREFIX ${CMAKE_CURRENT_BINARY_DIR}
DOWNLOAD_COMMAND ""
SOURCE_DIR ${CMAKE_SOURCE_DIR}/../external/googletest
BUILD_COMMAND make all
# Disable install step
INSTALL_COMMAND "")
# Create a libgtest target to be used as a dependency by test programs
set(LIBGTEST_STATIC ${CMAKE_CURRENT_BINARY_DIR}/.../googlemock/gtest/libgtest.a)
add_executable(unittest
"test/test_foo.cpp")
target_link_libraries(unittest main_app_lib
${LIBGTEST_STATIC}
${CMAKE_THREAD_LIBS_INIT})
NM output libgtest.a 1.8.0
user#system$ nm .../libgtest.a |grep MakeAndRegisterTestInfo
000000000000743a T _ZN7testing8internal23MakeAndRegisterTestInfoEPKcS2_S2_S2_NS0_12CodeLocationEPKvPFvvES7_PNS0_15TestFactoryBaseE
NM output libgtest.a 1.7.0 (working file)
user#system$ nm .../libgtest.a |grep MakeAndRegisterTestInfo
0000000000005968 T _ZN7testing8internal23MakeAndRegisterTestInfoEPKcS2_S2_S2_PKvPFvvES6_PNS0_15TestFactoryBaseE
Solved:
There was an old version of google test installed on build machine which headers were used by cmake.
#user1178014 answered his own question but since there are no posted answers I am writing it up:
If you downloaded the gtest source directly and used the make install from the downloaded gtest repository it may have installed header files under /usr/local/include/gtest. If you later use apt-get to install the libgtest-dev debian package it installs the header files under /usr/include/gtest. If the version installed from the debian package is newer, your Makefile can pick up the older header files from /usr/include and give you link errors even though you
are correctly linking the new libgtest.a archive.
The solution is to look for /usr/local/include/gtest and /usr/include/gtest to see if they both exist. If they do then delete the older directory. If /usr/include/gtest is the older directory, you may want to remove it by uninstalling the libgtest-dev package.
I installed Flex 2.5.4a and gcc compiler on windows. I also 've Dev-Cpp.
To compile the lex program, I used : flex file.l.
Now I got lex.yy.c, which I compiled using gcc compiler : gcc lex.yy.c.
It gave an error showing:
c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/../../../../mingw32/bin/ld.exe: cannot find -lfl
collect2.exe: error: ld returned 1 exit status
though I did include GnuWin32 bin path in path variable in environmental variables.Can someone tell me how to correct this error?
If you provide a main() and use option noyywrap, you don't need -lfl anymore...
%option noyywrap
%%
...your flex
%%
int main(){
yylex();
return 0;
}