Im trying to install a .pro file using 'make' on Debian-9. The dependencies are Qt5, GSL, libigl, Eigen and Boost, which their latest versions are installed.
I used the following:
# cd build
# qmake -qt=qt5 ../qt/myfile.pro
# make
And here is the error I get:
../libigl/include/igl/copyleft/boolean/../cgal/order_facets_around_edge.cpp:203:36: error: ‘Eigen::PlainObjectBase<Derived>::PlainObjectBase() [with Derived = Eigen::Matrix<int, -1, 1>]’ is protected within this context
Eigen::PlainObjectBase<DerivedI> positive_order, negative_order;
^~~~~~~~~~~~~~
In file included from /usr/local/include/eigen3/Eigen/Core:457:0,
from ../libigl/include/igl/copyleft/boolean/mesh_boolean.h:15,
from ../src/mesh.cpp:12:
/usr/local/include/eigen3/Eigen/src/Core/PlainObjectBase.h:484:25: note: declared protected here
EIGEN_STRONG_INLINE PlainObjectBase() : m_storage()
^~~~~~~~~~~~~~~
In file included from ../libigl/include/igl/copyleft/boolean/../cgal/order_facets_around_edge.h:75:0,
from ../libigl/include/igl/copyleft/boolean/../cgal/propagate_winding_numbers.cpp:18,
from ../libigl/include/igl/copyleft/boolean/../cgal/propagate_winding_numbers.h:101,
from ../libigl/include/igl/copyleft/boolean/mesh_boolean.cpp:13,
from ../libigl/include/igl/copyleft/boolean/mesh_boolean.h:172,
from ../src/mesh.cpp:12:
../libigl/include/igl/copyleft/boolean/../cgal/order_facets_around_edge.cpp:203:52: error: ‘Eigen::PlainObjectBase<Derived>::PlainObjectBase() [with Derived = Eigen::Matrix<int, -1, 1>]’ is protected within this context
Eigen::PlainObjectBase<DerivedI> positive_order, negative_order;
^~~~~~~~~~~~~~
In file included from /usr/local/include/eigen3/Eigen/Core:457:0,
from ../libigl/include/igl/copyleft/boolean/mesh_boolean.h:15,
from ../src/mesh.cpp:12:
/usr/local/include/eigen3/Eigen/src/Core/PlainObjectBase.h:484:25: note: declared protected here
EIGEN_STRONG_INLINE PlainObjectBase() : m_storage()
^~~~~~~~~~~~~~~
Makefile:891: recipe for target 'mesh.o' failed
Could someone please kindly help me solving the issue here?
This line
Eigen::PlainObjectBase<DerivedI> positive_order, negative_order;
won't compile. It may have once compiled for older Eigen versions -- but this is not how Eigen-Base types are supposed to be used, so it likely was never working as intended (that is also the reason why Base-constructors where made protected in Eigen).
However, that line does not exist in the most recent order_facets_around_edge.cpp, so you appear to be using an outdated libigl version.
Related
I've tried to get an audio library statically linked to my program. I use this nimble package. To get it run, i had to build the soloud library as described here. For short after download i ran "genie --with-miniaudio-only --platform=x64 vs2017" in the "build" folder and got the source code to generate the dynamic and the static library. For now i can run the following demo program from the nimble package with the generated dll alongside:
import solouddotnim, times, os
var i, spin = 0
var sl : ptr Soloud
sl = Soloud_create()
discard Soloud_init(sl)
Soloud_setGlobalVolume(sl, 1)
var stream = WavStream_create()
discard WavStream_load(cast[ptr Wav](stream), "test.ogg")
let currentTime = epochTime()
let length = WavStream_getLength(stream)
discard Soloud_play(cast[ptr Soloud](sl), cast[ptr Wav](stream))
while epochTime() - currentTime <= length:
sleep(100)
Soloud_deinit(sl)
Soloud_destroy(sl)
Now to the static-link part. In the solouddotnim.nim file of the nimble package i use, i see this part:
when defined(windows):
const
libname* = "libsoloud.dll"
elif ...
So i simple changed the windows part to the following, re-installed the nimble-package and placed the "soloud_static_x64.lib" alongside to the "main.nim" of the testproject:
when defined(windows):
const
libname* = "soloud_static_x64.lib"
elif ...
But this doesent make it. (cant open "soloud_static_x64.lib" error when build)
Evereywhere where the constant "libname" is used there are the pragmas "cdecl", "importc" and "dynlib". For example:
proc Soloud_create*(): ptr Soloud {.cdecl, importc: "Soloud_create", dynlib: libname.}
So "dynlib" is telling nim to use a dll on windows. But was is the pragma for static libraries?
In the nim documentations i only found DynlibOverride to link to static libraries, but i dont understand the example and here is where i stuck. I've tried the followings:
nim c --dynlibOverride:libname --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
nim c --dynlibOverride:soloudtotnim --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
Firstly i dont know what parameter dynlibOverride expects and secondly both compiles, but dont work. It expects a dynamic library alongside the exe.
My last try was to remove all dynlib pragmas from the nimble package. But now i cant compile it.
undefined reference to `Soloud_create'
...
Error: execution of an external program failed: 'gcc.exe...
My knowlege ends here. Can someone help me?
Thanks in advance.
Edit:
I could not get any of your solutions work. I break down the problem as small as possible so everybody can reproduce this:
"foo.nim" contains this:
proc add*(a, b: int): int {.cdecl, exportc.} =
a + b
proc sub*(a, b: int): int {.cdecl, exportc.} =
a - b
The .lib is simply generated with this command: "nim c --app:staticlib foo.nim"
Now to use it i created a file "main.nim" with this content:
{.passL:"foo.lib".}
proc add*(a, b: int):int {.cdecl, importc.}
proc sub*(a, b: int):int {.cdecl, importc.}
echo add(10, 5)
echo sub(10, 5)
if i simply build it with "nim c -r main.nim", i get the following output and error:
P:\Nim\LearnCBinding>nim c -r main.nim
Hint: used config file 'C:\nim-1.5.1\config\nim.cfg' [Conf]
Hint: used config file 'C:\nim-1.5.1\config\config.nims' [Conf]
....CC: stdlib_io.nim
CC: stdlib_system.nim
CC: main.nim
Hint: [Link]
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x1f6): multiple definition of `PreMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x120): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x20a): multiple definition of `PreMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x134): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x240): multiple definition of `NimMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x16f): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x254): multiple definition of `NimMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x183): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x285): multiple definition of `main'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x1b4): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x2da): multiple definition of `NimMainModule'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x209): first defined here
collect2.exe: error: ld returned 1 exit status
Error: execution of an external program failed: 'C:\nim-1.5.1\dist\mingw64\bin\gcc.exe -o P:\Nim\LearnCBinding\main.exe C:\Users\Peter\nimcache\main_d\stdlib_io.nim.c.o C:\Users\Peter\nimcache\main_d\stdlib_system.nim.c.o C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o foo.lib '
Because of the multiple definition error i also tried to build foo.lib with parameter "--noMain:on", but it doesnt make any difference.
Do you have the same problem? By the way i use the current version of Nim "nim-1.5.1" and reinstalled MingW with the finish.exe from nim.
I will try to help you with the following error you have:
undefined reference to `Soloud_create'
but i will assume that you have configured your environment so you can compile your nim programs with visual studio compiler (by adding --cc:vcc to your compile command)
this is because you already seem to have visual studio 2017 and you are compiling soloud static library with it. I think this is the best option when you are compiling with one compiler both: static library and executable that will use it.
open your static library (soloud_static_x64.lib) with some text/hex editor and search for "Soloud_create". i guess you will not find anything. so why is that? because for some reason author decided to not include "C interfacing" in a static library project. so it contains only C++ symbols and not pure C symbols that are needed for our solouddotnim.nim module.
let's try to find out what .cpp file we need for that. i noticed this information on official web site of Soloud - http://sol.gfxile.net/soloud/c_api.html
so i guess we need only one file: soloud_c.cpp
let's try to just include it in SoloudStatic.vcxproj file generated by you with Genie. like this:
..
<ClCompile Include="..\..\src\c_api\soloud_c.cpp">
</ClCompile>
..
and recompile our static library. i use this command in powershell:
& 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\MSBuild.exe' /p:PlatformToolset=v142`;WindowsTargetPlatformVersion=10`;Configuration=Release`;Platform=x64 .\SoloudStatic.vcxproj
but you can compile how you want. just make sure that it's architecture is really x64. you can check it with this command:
dumpbin /headers soloud_static_x64.lib | more
finally just link it with your nim file. add this line to the top:
{.link:"soloud_static_x64.lib".}
and compile nim file with this command:
nim c --cc:vcc --dynlibOverride:libsoloud.dll -r "examples\00-ogg\Example00_ogg.nim"
In file included from ./Market.h:6:
In file included from
/Users/shubhamsharma/projects/liquibook/src/book/depth_order_book.h:6:
/Users/shubhamsharma/projects/liquibook/src/book/order_book.h:559:17:
error: no member named 'emplace' in
'std::__1::multimap<liquibook::book::ComparablePrice,
liquibook::book::OrderTracker<std::__1::shared_ptr<orderentry::Order> >,
std::__1::less<liquibook::book::ComparablePrice>, std::__1::allocator<std::__1::pair<const
liquibook::book::ComparablePrice, liquibook::book::OrderTracker<std::__1::shared_ptr<orderentry::Order> > > >
>'
stopBids_.emplace(key, std::move(tracker));
I have set all the environment variables, Makefile is generated using MPC, The error comes after make all. I have tried upgrading my gcc to 4.9 but still the same error occurs. Please help!
This is kind of a specific question, but, I am unable to get cmake and make to compile Yet Another Prolog in Fedora 23. Cloned the latest repo on Github, YAP 6.3.4. My friend ran cmake and make successfully on the identical clone on his Funtoo Linux. When I run them on Fedora 23, I get weird errors that would only make sense if CUDD headers were missing, but CUDD is installed with the header files.
I hope anyone has enough experience to offer a reason why a cmake-generated Makefile would fail to compile in one Linux system while compiling on another.
Here is a sample of the make errors (Makefile made with cmake with no errors). The "unknown" type name is in CUDD headers which are installed on my system. The source file cplint is supposed to be built using CUDD
% YAP 6.3.4-76638bb7 (compiled 2016-09-01T01:01:57#dhcp-129-8-62-64)
In file included from /home/safulop/yap-6.3/packages/cplint/cplint_yap.c:15:0:
/home/safulop/yap-6.3/packages/cplint/cplint.h:41:3: error: unknown type name ‘DdNode’
DdNode * * booleanVars;
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:54:3: error: unknown type name ‘DdNode’
DdNode *key;
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:64:33: error: unknown type name ‘DdManager’
variables createVars(YAP_Term t,DdManager * mgr, int create_dot,
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:69:1: error: unknown type name ‘DdNode’
DdNode * retFunction(DdManager * mgr, expr expression,variables v);
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:69:22: error: unknown type name ‘DdManager’
DdNode * retFunction(DdManager * mgr, expr expression,variables v);
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:70:1: error: unknown type name ‘DdNode’
DdNode * retTerm(DdManager * mgr,term t,variables v);
^
As you said, the problem cames from the CUDD library. You need to fix the include directory folders of CUDD in the Makefile...
Hi I am trying to work with the rcpp. For this I want some cpp code which loads a dll by use of a lib-file (which has the same name as ). the code which I let run is:
cppFunction(includes=c("#include "windef.h","#include \"C:/data/Rdata/IHUAPI.H\" "), 'int functietom(int a){long serverhandle;int lRet;lRet = ihuConnect ( "historian1",NULL,NULL, &serverhandle ); return 5;}', verbose
= TRUE)
I get the following error:
undefined reference to `ihuConnect#16' collect2: ld returned 1 exit
status Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object
'C:/Users/user1663/AppData/Local/Temp/RtmpSW1Ki7/sourcecpp_1a04df63309/sourceCpp_26588.dll':
LoadLibrary failure:
the ihuConnect function is located in the ihuapi.lib and ihuape.dll files. In c++ in visual studio I add the lib file as added dependency and then I get rid of this error because I also sometimes get this error and then it was that I forgot to add the lib file in the compilation.
Thus My question is: how can I add this lib file as option in the compilation.
when I use dyn.load
("C:/data/Rdata/ihUAPI.dll")
and then check if it is loaded then he says yes
the problem is that getDLLRegisteredRoutines('ihUAPI', addNames = TRUE)
then it says:
data frame with 0 columns and 0 rows
so the dll seems not to contain the functions but it does when I use it from visual studio.
So please some help with lib-files and ddl-files
Tom Wambecq
You missed the Rcpp FAQ entry 2.9 'Can I use Rcpp with Visual Studio ?'.
And to kill all the suspense: No, you cannot.
I created simple application, which uses sqlite3 as it's datastore back-end. I faced no problems when building and running it on Linux, but after I tried to build it on Windows, I see weird linking error:
Linking dist\build\hnotes\hnotes.exe ...
C:\Documents and Settings\Admin\Application Data\cabal\sqlite-0.5.2.2\ghc-7.0.4/libHSsqlite-0.5.2.2.
a(sqlite3-local.o):sqlite3-local.c:(.text+0x21): undefined reference to `sqlite3_temp_directory'
C:\Documents and Settings\Admin\Application Data\cabal\sqlite-0.5.2.2\ghc-7.0.4/libHSsqlite-0.5.2.2.
a(sqlite3-local.o):sqlite3-local.c:(.text+0x40): undefined reference to `sqlite3_temp_directory'
collect2: v ld 1
cabal.EXE: Error: some packages failed to install:
hnotes-0.1 failed during the building phase. The exception was:
ExitFailure 1
What may be wrong there? I suspect that qalite3.dll has to be added to linking stage, but have no idea how to do that. Adding --extra-lib-dirs=path-to-sqlite-dll doesn't help either (perhaps because I need to update my cabal file somehow, to support this?).
Not sure if It's a bug or not, but the error comes from the sqlite3.h include of the sqlite package.
A look in the file shows this
/*
** CAPI3REF: Name Of The Folder Holding Temporary Files {H10310} <S20000>
**
** If this global variable is made to point to a string which is
** the name of a folder (a.k.a. directory), then all temporary files
** created by SQLite will be placed in that directory. If this variable
** is a NULL pointer, then SQLite performs a search for an appropriate
** temporary file directory.
**
** It is not safe to modify this variable once a [database connection]
** has been opened. It is intended that this variable be set once
** as part of process initialization and before any SQLite interface
** routines have been call and remain unchanged thereafter.
*/
SQLITE_EXTERN char *sqlite3_temp_directory;
so it's declared as an extern. So simple test:
module Main where
import Database.SQLite
main
= do hwd <- openConnection "test"
closeConnection hwd
putStrLn "done"
This crashes during linking as expected with the error you have above.
So I created a small C test file foo.c
#include "sqlite-0.5.2.2\\include\\sqlite3-local.h"
char* sqlite3_temp_directory = "C:\\test2";
So I'm defining a temp_directory and then I pass the c file along during compilation of the haskell source
$ ghc test.hs foo.c
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test.exe ...
and then running it also returns the expected result
$ ./test
done
So it seems that you just need to give a value for the sqlite3_temp_directory, which if you set it to a NULL pointer will use the TMP/TEMP etc variables as defined in the SQLLITE manual.
edit, follow up on why it worked on Linux but not on windows
In the sqlite package, there's a file sqlite3.c under the folder sqlite3.6. This provides a bunch of defaults for the sqlite package.
when on linux OS_UNIX is defined and when on linux it uses the defines under OS_WIN.
The function we're interested in is the function which sets the temporary directory. for unix this'll be unixGetTempname and for windows winGetTempname.
If you look at the implementation of both these functions, for the unix one it has list of directories that it'll try
static const char *azDirs[] = {
0,
"/var/tmp",
"/usr/tmp",
"/tmp",
".",
};
it tries to access them in order and the one it can write to it uses to generate a temporary folder in.
For windows however one of the first lines are:
if( sqlite3_temp_directory ){
sqlite3_snprintf(MAX_PATH-30, zTempPath, "%s", sqlite3_temp_directory);
}else if( isNT() ){
so for windows sqlite3_temp_directory is actually used. This is why it doesn't compile if It can't find it.