I found this project by Sony which serves as a wrapper around the V8 engine that exposes just enough functionality to be useful.
As is, the project references V8 version 7.1.177. I was trying to update to version 7.9.317.31.
The following is the v8gen invocation:
tools/dev/v8gen.py x64.release -- v8_use_snapshot=false v8_enable_i18n_support=false
And the following is the Ninja invocation:
ninja -v -C out.gn/x64.release
The issue I'm having is that when I change the version indicated in the build script I encounter a build error complaining about the directory /v8/out.gn/x64.release/obj/v8_base is missing. My guess is that v8_base is now called something else, but I can't find that documented anywhere.
I'm a bit out of my depth here so I'm not really sure where I should even start looking as far as documentation goes.
Related
I use version 4.1.1 of GTSAM. I have version 3.3.4 of Eigen installed.
The error is:
/usr/local/include/gtsam/base/OptionalJacobian.h:22:10: fatal error: Eigen/Dense: No such file or directory
#include <Eigen/Dense>
I tried building GTSAM with the flag -DGTSAM_USE_SYSTEM_EIGEN set to both on and off.
The same error message appears in both cases.
For reference this is a ROS project built with catkin.
Have you seen this PR: https://github.com/borglab/gtsam/pull/1304
If you can upgrade GTSAM to 4.2a8, it uses Eigen's find script's rather than custom ones and should properly find Eigen3, if you have it installed if you require to build from source.
Since you are using ROS, why not go the standard route... Have you declared a dependency on it in your package.xml and installed it with rosdep?
https://github.com/ros/rosdistro/pull/23198/files
Add to your package.xml:
<depend>gtsam</depend>
And, your CMakeLists, you just call
find_package(gtsam REQUIRED)
It is unclear to me, if gtsam is available through binaries, why you would be building it from source.
I was able to get it working by cloning version 4.0.3 of GTSAM into the src folder of my workspace, then building it with the following arguments:
-DGTSAM_USE_SYSTEM_EIGEN=ON -DGTSAM_POSE3_EXPMAP=ON -DGTSAM_ROT3_EXPMAP=ON
I've been trying to install hmatrix on my (64-bit) Windows 10 computer; after searching through and trying many possible solutions (including the instructions under "Windows" and "Alternative Windows Build" given here), I decided to pursue the course of action given on this Reddit thread.
However, when I type in the command
cabal install hmatrix -fopenblas --extra-lib-dir=${c:\msys64\mingw64\bin} --extra-include-dir=${c:\msys64\mingw64\include}
into the MSYS2 shell, the following log is given:
Resolving dependencies...
Configuring hmatrix-0.17.0.2...
Failed to install hmatrix-0.17.0.2
Build log ( C:\Users\Christian\AppData\Roaming\cabal\logs\hmatrix-0.17.0.2.log ):
Configuring hmatrix-0.17.0.2...
cabal.exe: Missing dependency on a foreign library:
* Missing C library: libopenblas
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Leaving directory 'C:\msys64\tmp\cabal-tmp-4244\hmatrix-0.17.0.2'
cabal.exe: Error: some packages failed to install:
hmatrix-0.17.0.2 failed during the configure step. The exception was:
ExitFailure 1
However, when I check the directory c:\msys64\mingw64\bin, I see that libopenblas.dll is right there; I don't know why cabal can't seem to find it.
Any insight into why this is not working or what to do?
UPDATE:
The files libopenblas.dll.a and libopenblas.a are in the directory c:\msys64\mingw64\lib. Is it possible I need to somehow include this directory as well? (If I do, how would I do that?)
I also downloaded the files in Alex Vorobiev's comment below and put them in c:\msys64\mingw64\bin if they are .dlls or c:\msys64\mingw64\lib if they are .libs. The header files were already contained in c:\msys64\include\openblas.
I tried several variations on the command in the original post after making these changes, including switching \bin with \lib and switching \include with \include\openblas, but all of them still give the same error.
I'm a bit suspicious about the
if os(windows)
if flag(openblas)
extra-libraries: libopenblas
in the cabal file, could you unpack it and remove the "lib" part? If that doesn't work please post a log with -v3 output. I've seen quite a few people with troubles installing this package. So could you also open a ticket on the GHC bug tracker if this doesn't work (and CC me "Phyx-")?
Secondly, you never said which version of GHC you're using. 8.0.1 should have far less trouble (and won't need the hack to get it working in GHCi) since the runtime linker has been overhauled and should be much better on Windows. 8.0.2 will likely include the new import libraries support as well.
I am trying to build xmlsec on Windows... I am not an experienced C/C++ developer and not really familiar with the build process if something along the lines of "make ... make install" doesn't do the trick.
xmlsec comes with a Win32 subdirectory, a nice ECMAScript configure.js that takes an optional bunch of parameters and a readme which explains that after running the configure, "nmake ... nmake install" should do the trick. (Obviously it isn't quite that easy or I wouldn't be posting here!)
xmlsec also depends on a number of other libraries (see here for a graphic). I have downloaded the sources for those libraries.
My problem is that I don't know how to arrange those sources, or what to tell the configure.js script, in order to get a build to work.
For instance, the nmake process complains that it can't find "iconv.h" (iconv is one of the required libraries), which is not surprising because there isn't one. Instead there is an "iconv.h.in" and an "iconv.h.build.in"... which I don't know what to do with to produce the required 'iconv.h".
(I am using MS Visual Studio 2010 at the command prompt (which I think is the recommended approach.)
Does anybody out there know how to do this? Any help at all would be very much appreciated.
TIA
Mike Peat
You don't need to build xmlsec, you can directly download the wheel file from this link
https://github.com/mehcode/python-xmlsec/releases
It has all the dependencies installed with it.
have you tried the Msys with Mingw32 compiler? In Msys, you can do make and make install trick. I have successful with Msys in compile xmlsec. If you want to use Msys and have difficulties, I can help.
Anyway, in general, there must be a iconv.h file in the pre-compile folder provided by Zlatkovic (i.e C:\iconv\include\iconv.h). You may want to download again the folder. After figure out where all the dependencies are, put the path in environment path. For your information, I once tried with the configure.js but not successful. Hope that you are luckier than me :D
Hi Kristine (#Kristine T) - (and thanks for getting back to me!)
I had not been doing "make clean", but have now done so ("make clean", followed by "make" - no change in the result though).
The problem I get with the "make" is that it throws an error on compiling "dl.c" saying that "PACKAGE" is undefined (line 295).
I have also had problems using the compiled version of libxml2 - "configure" always says it can't find it (it is there, but...), so I have been using the --with-libxml-src=... parameter to configure, giving it the full source of libxml2 to work with, getting configure to at least finish OK.
I don't have the same problems with openssl or libxslt where I can either tell configure about the compiled version (using --with-XXX={path-to-dir}, or just omit ={path} bit, in which case it seems to find MinGW's own versions, but that doesn't work with libxml2.
Mike
I spent the whole day setting up GCC as per
http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0
On the gcc make step, it told me it needed a c++ compiler to continue for whatever reason,
So I updated Cygwin in the usual fashion and got gcc-c++.
After that, cgywin did me the courtesy of deleting the 3 prereq libraries that I had installed previously,
So I went about remaking them. GMP worked fine, and then I got to MPFR. For whatever reason MPFR is throwing this error:
configure: error: libgmp not found or uses a different ABI.
The resources mention this error here.
I’m pretty sure its finding GMP alright as cygcheck shows it up no problem, and the config even mentions it finds it.
When I try:
./configure --with-gmp-build=/gmp/,
it throws:
error: header files gmp-impl.h and longlong.h not found
So far I have not been able to get MPFR working, despite googling and trying for hours.
MPC also fails to find GMP in the usual manner.
I've also tried just handing the libraries to GCC in a subdirectory and letting it compile them.
When I try that, it gets to the make step, then throws a stage1-bubble error and fails. No description of the error or anything.
I have no idea what else to try.
After compiling and installing gmp, I had the same problem building mpfr until I set correctly the library search path:
export LD_LIBRARY_PATH=/usr/local/lib
export LIBRARY_PATH=/usr/local/lib
export CPATH=/usr/local/include
as it is explained in the http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0
Instead of this:
./configure --with-gmp-build=/gmp/
USE THIS:
./configure --with-gmp-build=/gmp
It doesn't like having the "/" at the end.
I know this post is a bit dated, but I was looking for an answer or results to a similar situation but with much more current versions of the same libraries. While reading this post as for some suggestions as well as other online material I was able to piece everything together. So for anyone who may be working with the newest releases here it goes:
First you will probably want to configure, make and install GMP first for both C and C++ as static libs; also make note of the architecture x86 or x64. Once you run make, make check, make install; and you are confidant that you have no errors, then when you go to configure MPFR you will want to run it as such:
./configure --with-gmp-build=/path/to/gmp --enable-static --disable-shared
and if the paths are set properly this should give you the needed generated make file.
I'm brand new to Unix-Posix environments and commands and new to Cygwin. I've mostly used Windows platforms and very few Macs or Apples. Matter of fact I've only been working at this for a little less than a week as I'm trying to do the same thing. So now I'm venturing into a whole new world of Unix... but it's sort of simulated through Cygwin as I'm still running windows.
I'm trying to build GMP, MPIR, MPFR & MPFRC++ all from the latest original distributions and eventually will try to integrate them into Visual Studio 2017.
I had actually found this post because I was able to build MPIR through visual studio with the help of python and vyasm, but as for GMP I needed Cygwin with GCC. It took me a little while to figure out how to get GMP to build properly but once I did and ran the tests I was able to have all pass with 0 failures. I then started to work with MPFR the same as you.
My similar issue was after I ran ./configure as default, it was giving me the message that the libgmp wasn't found. Also if I tried to call make, it would do nothing as the make file didn't exist. This led me back to doing google searches... While searching for tips, suggestions etc. I came across this Q/A. While I was reading this Q/A, the install files, some other FAQ and even another website, I was kind of able to piece everything together and what I have found that works is what I suggested above.
Not only do you need to set the flag --with-gmp-build but you also need to set the appropriate library types that gmp was built as and you need to make sure that the architecture types match too. They need to have the same matching ABIs.
Ah, just as I was about to finish up typing this answer, make check just finished running through Cygwin and I have a result of:
Testsuite summary for MPFR 4.0.1
============================================================================
# TOTAL: 180
# PASS: 180
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
I hope this helps you out. The only thing is for myself; I'll have to go back and probably run all of this again from the beginning including GMP only because I believe I only did GCC and not G++ and my next step is to try and build MPFRC++.
Then I might try to do some related libraries from here afterwards. My first phase is to try to build them all through Cygwin and GCC/G++. The next step will be to try and port them over to Visual Studio 2017.
You might want to use --with-gmp-lib=/path/to/gmp/lib/dir
I'm trying to get Bison to do it's thing in VC6. I'm sure this must be a problem with my configuration. At the moment I have a Custom Build step as follows.
<Commands>
echo Start parser generation
"C:\GnuWin32\bin\bison.exe" $(InputPath)
echo Finish parser generation
<Outputs>
$(ProjDir)\$(InputName).c
$(ProjDir)\$(InputName).h
The error I get is "C:\GnuWin32\bin\bison.exe: m4: No such file or directory", which makes me think the m4.exe doesn't exist or isn't on the path, but I can run the exact same command from CMD in the same directory with no errors.
This thought process makes me think it's a problem with the output options, but I've tried various configurations with no luck.
Any help would be great, thanks in advance.
Edit: I've added some more visual studio versions to the tag list to try to get some more exposure for the question. Hopefully someone will have done this in a later version and I can work backwards.
Okay, I've managed to slove this in a very round-about way but I will try my best to document it here.
It seems that VC6 Custom build options will only look in the project directory for the m4.exe, even when you specify where the calling exe (bison) is explicitly. To solve this I did a bit of a hack and did a full cd command in the custom build window to get to the gnuwin32 directory (where both bison and m4 live) before trying to call the parser generator.
This works fine but is a bit of a hassle for trying to distribute it to other people when they may have installed GNU tools to a different location.