I am unable to build some of the CGAL examples under Cygwin. All of the failing examples share similar error messages.
Any guidance would be most appreciated.
Following are the steps that I followed and a sample error from a "make".
Cygwin (x64) installed under Windows 7 to d:\cygwin64.
CGAL source downloaded from https://github.com/CGAL/cgal/releases/download/releases%2FCGAL-4.9/CGAL-4.9.zip
and unzipped to D:\cygwin64\usr\CGAL-4.9
All libraries supposedly needed for CGAL were installed via the Cygwin x64 setup.
Initial cmake:
cd /usr/CGAL-4.9
cmake -DCMAKE_LEGACY_CYGWIN_WIN32=1 -DWITH_CGAL_Qt5=OFF -DWITH_examples=ON .
Some examples could not be configured, these included the mesh and Scale_space_reconstruction_3 examples.
cd /usr/CGAL-4.9
make
make examples
The first few examples were created successfully. For example,
PATH=/usr/local/bin:/usr/bin:/bin:/lib:/usr/CGAL-4.9/bin:/usr/CGAL-4.9/lib
cd /usr/CGAL-4.9/examples/AABB_tree
./AABB_triangle_3_example.exe
3 intersections(s) with ray query
closest point is: 0.333333 0.333333 0.333333
squared distance: 8.33333
A later example demonstrates a nagging problem that shows up in a number of the examples:
cd /usr/CGAL-4.9/examples/Snap_rounding_2/
cmake -DCGAL_DIR=/usr/CGAL-4.9 .
make
Scanning dependencies of target snap_rounding
[ 16%] Building CXX object CMakeFiles/snap_rounding.dir/snap_rounding.cpp.o
In file included from /usr/CGAL-4.9/include/CGAL/CORE/CoreDefs.h:41:0,
from /usr/CGAL-4.9/include/CGAL/CORE/BigFloatRep.h:40,
from /usr/CGAL-4.9/include/CGAL/CORE/BigFloat.h:38,
from /usr/CGAL-4.9/include/CGAL/CORE_BigFloat.h:27,
from /usr/CGAL-4.9/include/CGAL/CORE_arithmetic_kernel.h:39,
from /usr/CGAL-4.9/include/CGAL/Arithmetic_kernel.h:51,
from /usr/CGAL-4.9/include/CGAL/Arr_rational_function_traits_2.h:28,
from /usr/CGAL-4.9/include/CGAL/Sweep_line_2_algorithms.h:37,
from /usr/CGAL-4.9/include/CGAL/Snap_rounding_2.h:28,
from /usr/CGAL-4.9/examples/Snap_rounding_2/snap_rounding.cpp: :
/usr/CGAL-4.9/include/CGAL/CORE/extLong.h:171:8: warning: ‘CORE::extLong::extLong(int)’ redeclared without dllimport attribute after being referenced with dll linkage
inline extLong::extLong(int i) : val(i), flag(0) {
^
/usr/CGAL-4.9/include/CGAL/CORE/extLong.h:292:13: warning: ‘bool CORE::extLong::isNaN() const’ redeclared without dllimport attribute after being referenced with dll linkage
inline bool extLong::isNaN() const {
There are a number of similar errors that have been omitted here.
Thanks!!!
As the errors, that you are not reporting, are likely due to wrong importing directive, you can try the following:
On include/CGAL/export/helpers.h
replace
# if defined(_WIN32) || defined(__CYGWIN__)
with
# if defined(_WIN32)
and then build with
cmake -DWITH_CGAL_Qt5=OFF -DWITH_examples=ON
for what I see the build works much better (20% done in one our and still going)
Related
I am trying to build openvibe! source code on raspbian and i have installed all the required dependencies, one by one manually, but in the end it seems to have a compilation error.
So after writing build files it says:
-- Build files have been written to: /home/pi/Desktop/openvibe-2.0.0-src/build/sdk-Release
Generation succeeded!
Building project...
and:
[1/340] Building CXX object build-tool...
[some dirty code here]
and then stops building sdk
returning this :
c++: error: unrecognized command line option ‘-msse2’
ninja: build stopped: subcommand failed.
ERROR: Build failed
Error while building sdk
I want to make it clear that i have searched everywhere and SOF is my last resort! So any help would be highly appreciated!
Judging by the output, you are building the library using cmake.
-msse2 is gcc compilation flag, which enables x86 sse vectorisation. Since you are compiling for raspbian you need to disable it.
Usually, compilation flags are set in CMakeLists.txt files. Find, the place where it was set:
find . -name CMakeLists.txt | xargs grep msse2
You will find something like:
# Switch -msse2 enables vectorization. Remove if your CPU/compiler doesn't support it.
SET(OV_EIGEN_FLAGS "-msse2")
As guided, remove every occurrence, and you are done.
I'm following this guide on building V8 but I am hitting some issues on the compilation step. I am running Windows 10 x64. I am trying to compile with options to embed the engine also.
Running the following command:
ninja -C out.gn/x64.release
Gives me this error:
ninja: Entering directory `out.gn/x64.release'
[1/471] LINK mksnapshot.exe mksnapshot.exe.pdb
FAILED: mksnapshot.exe mksnapshot.exe.pdb
C:/Workspace/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb #./mksnapshot.exe.rsp
LINK : fatal error LNK1181: cannot open input file 'comdlg32.lib'
ninja: build stopped: subcommand failed.
Now I believe I have narrowed down the error to looking for the .lib files in the wrong directory. I have (had) multiple versions installed, so there were multiple folders in my Windows Kit install.
Windows Kits/10/Lib/10.0.16299.0
Windows Kits/10/Lib/10.0.15xxx.0
If I dragged and dropped the comdlg32.lib file from 10.0.16299.0 into the 10.0.15xxx.0 directory then the error changed to a LNK1181 error with a different input file. I did this a few times but I was unsure if this was going to cause issues with different versions and there was probably going to be a lot.
I uninstalled the 10.0.15xxx.0 version which left behind the folder I mentioned, so I removed that and after doing so I have started getting the LNK1181 error with a different input file (advapi32.lib I assume the very first file it can't find). This is how I came to the conclusion about the path being incorrect.
So I have tried a few things to change the path (I hoped just uninstalling the old version would fix it) such as:
Uninstalling the old version.
Going through registry entries to see if I can find an install path or something using that path, which I didn't. I did notice that there was still installation and data in the registry for the 10.0.15xxx.0 install, I might try deleting that from the registry directly as a last resort?
I have tried to explicitly set the path by setting <TargetUniversalCRTVersion>10.0.16299.0</TargetUniversalCRTVersion> in this file: C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\uCRT.props
I have never used Ninja before so I tried looking for a way to set some kind of lib-path in the command but couldn't really find anything.
I looked through the python scripts being executed to try and locate something to do with the libs path but couldn't see anything.
I would be grateful for any help and suggestions. Thanks.
You can try to compile v8 using Visual Studio as explained here: https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#using-the-visual-studio-ide
By running the following commands:
$ gn gen --ide=vs out.gn/x64.release
$ cd out.gn/x64.release
$ msbuild all.sln
You can see a full example here: https://github.com/phpv8/v8js/issues/272#issuecomment-262848754
Apparently this method is not officially supported anymore, but I had the same problem as you have and this solved the issue for me.
Note that after this I had another issue, the unit tests failed to be compiled due to a linking error, but I had the necessary libraries to use v8. So there may be deeper problem that is causing all of this that I'm missing.
Edit:
Also, you could try to set the following parameters with gn args:
visual_studio_path = "..."
visual_studio_version = "2017"
wdk_path = "..."
windows_sdk_path = "C:\Program Files (x86)\Windows Kits\10"
To set those parameters, do:
gn args out.gn/x64.release
This will open a text editor where you can write the extra parameters you are interested in.
To see the full list of parameters you can specify:
gn args --list out.gn/x64.release
I was following this guide https://medium.com/dailyjs/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4 and also ran into the error
LINK1181: cannot open input file 'advapi32.lib'
I'm pretty sure it was because I had the wrong versions of the Windows 10 SDK. Similar to you I had versions:
Windows Kits/10/Lib/10.0.10240.0
Windows Kits/10/Lib/10.0.16299.0
But according to https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows (Which I think is relevant) you need version 10.0.15063.0
After installing version 10.0.15063.0 (with the visual studio installer) to
Windows Kits/10/Lib/10.0.15063.0
I was able to continue with the build.
Yet another linux build newb here, struggling to build mariadb-client for Android using the NDK.
I have already succesfully built openssl and libiconv, which are perquisites.
Here is what I am doing:
export ANDROID_NDK_ROOT="/home/dev/android-ndk-r12b"
SR="$ANDROID_NDK_ROOT/platforms/android-16/arch-arm"
BR="$ANDROID_NDK_ROOT/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-"
mkdir build && cd build
PKG_CONFIG_PATH=$SR/usr/lib/pkgconfig cmake -DCMAKE_AR="$BR"ar -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER="$BR"gcc -DCMAKE_C_FLAGS=--sysroot=$SR -DCMAKE_INSTALL_PREFIX=$SR/usr -DCMAKE_LINKER="$BR"ld -DCMAKE_NM="$BR"nm -DCMAKE_OBJCOPY="$BR"objcopy -DCMAKE_OBJDUMP="$BR"objdump -DCMAKE_RANLIB="$BR"ranlib -DCMAKE_STRIP="$BR"strip -DWITH_EXTERNAL_ZLIB=ON -DICONV_INCLUDE_DIR=$SR/usr/include -DICONV_LIBRARIES=$SR/usr/lib/libiconv.a -DZLIB_INCLUDE_DIR=$SR/usr/include -DZLIB_LIBRARY=$SR/usr/lib/libz.so ../
make install
To break down that last part so it is more readable:
PKG_CONFIG_PATH=$SR/usr/lib/pkgconfig
cmake
-DCMAKE_AR="$BR"ar
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_C_COMPILER="$BR"gcc
-DCMAKE_C_FLAGS=--sysroot=$SR
-DCMAKE_INSTALL_PREFIX=$SR/usr
-DCMAKE_LINKER="$BR"ld
-DCMAKE_NM="$BR"nm
-DCMAKE_OBJCOPY="$BR"objcopy
-DCMAKE_OBJDUMP="$BR"objdump
-DCMAKE_RANLIB="$BR"ranlib
-DCMAKE_STRIP="$BR"strip
-DWITH_EXTERNAL_ZLIB=ON
-DICONV_INCLUDE_DIR=$SR/usr/include
-DICONV_LIBRARIES=$SR/usr/lib/libiconv.a
-DZLIB_INCLUDE_DIR=$SR/usr/include
-DZLIB_LIBRARY=$SR/usr/lib/libz.so
The first error I got was that program_invocation_short_name was undefined in this bit of code:
#elif defined(_GNU_SOURCE)
const char * appname = program_invocation_short_name;
#elif defined(WIN32)
I couldn't find why this is and how to fix, so I decided to cheat my way through by assigning an empty string to it. Possibly with negative repercussions, but I noticed the source doing the same thing a few lines down so I decided to give it a go nonetheless.
Another build attempt, and now I am getting undefined references for iconv functions:
CMakeFiles/mariadb_obj.dir/ma_charset.c.o:ma_charset.c:function mariadb_convert_string: error: undefined reference to 'iconv_open'
CMakeFiles/mariadb_obj.dir/ma_charset.c.o:ma_charset.c:function mariadb_convert_string: error: undefined reference to 'iconv'
CMakeFiles/mariadb_obj.dir/ma_charset.c.o:ma_charset.c:function mariadb_convert_string: error: undefined reference to 'iconv_close'
CMakeFiles/mariadb_obj.dir/ma_context.c.o:ma_context.c:function my_context_spawn_internal: error: undefined reference to 'setcontext'
CMakeFiles/mariadb_obj.dir/ma_context.c.o:ma_context.c:function my_context_continue: error: undefined reference to 'swapcontext'
The libraries are definitely there, as defined in the configuration above. Maybe that's a side effect of the above cheat?
Or maybe something else entirely is going wrong?
Once again, a complete newb in this regard, but I get a newb hunch that it may have something to do with cmake. Is it possibly using the host machine cmake but should be using some "android toolchain" cmake instead? I couldn't find much info on that either, but it could explain why it isn't picking the program_invocation_short_name thingie and the libs.
So, any ideas what is going wrong and how to fix it?
The build env should be clear by the first few lines of code but just in case, it's Ubuntu 16.04 x64, using NDK r12b and the GCC 4.9 toolchain. I am using the following versions of the libraries: libiconv 1.15, openssl 1.1.0f and mariadb_connector_c 3.0.3.
Currently MariaDB Connector/C doesn't support Android NDK, this is planned for the upcoming 3.0.3 release.
To build MariaDB Connector/C with Android NDK you need to checkout the 3.0-portable branch of MariaDB Connector/C.
Iconv support currently doesn't work, same is valid for Kerberos/GSSAPI authentication plugin.
For building MariaDB Connector/C with Android NDK you have specify additionally the following CMake parameters:
-DWITH_ICONV=OFF -DWITH_DYNCOL=OFF -DAUTH_GSSAPI_TYPE=OFF
If you don't need SSL/TLS support, you can disable it by specifying
-DWITH_SSL=OFF
I start saying that i am a newbie in programming and then i am not sure i will be able to explain well my problem.
I had some c++ code i wrote, this code are loaded and used by some R functions.
To compile the code i used the following:
R CMD SHLIB MyCode.cpp
and i loaded the library in R with
dyn.load("MyCOde.so")
Sometimes i built also an R package and i was able to load it into R.
If i do all these stuff on a Mac with mountain lion everything work fine, but now that i switched to mavericks, i have some problems. The R CMD SHLIB MyCode.cpp command works but when i used dyn.load("MyCOde.so") i get the following text:
Errore in dyn.load(paste(dir_function, "MyCOde.so", sep = "")) :
unable to load shared object 'MyCOde.so':
dlopen(MyCOde.so, 6): Symbol not found: __ZNSt8ios_base4InitC1Ev
Referenced from: MyCOde.so
Expected in: flat namespace
in MyCOde.so
Moreover if i try to load the package in R, i get the following
ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
ld: library not found for -lquadmath
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [MyCode.so] Error 1
Can someone helps me?
Based on the helpful website of:
thecoatlessprofessor
Type this into your terminal shell:
curl -O http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
sudo tar fvxz gfortran-4.8.2-darwin13.tar.bz2 -C /
This will create what you need to resume compiling as before.
Since it starts to work I can publish the answer for such a cases.
When you change the compiler and standard libraries - please note that different libraries have different implementation and different standard support. Changing the basement of your system might require total rebuild of your system with the new C++ standard library.
Your libraries are not the exception. So if have the errors in your linker like this:
warning: directory not found for option
'-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
apply next algorithm:
Check whether the directory /usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 still exists. I bet it is not.
Check if you still have the libstdc++ from the missed compiler? Usually if you upgrade the same compiler and the C++ standard library ABI does not change everything should continue to work. If the ABI changed or you switch standard C++ library and compiler - you face the massive system rebuild.
Recompile your library and apps with the new C++ standard library and compiler.
I'm trying to build a moderately sized Symbian Qt project (around 100 files) using the latest released Nokia Qt SDK (Qt 4.6.3 and Qt Mobility 1.0.2).
The build for the simulator finishes in under 3 minutes, but when I build for the device, the build takes well over 20 minutes! I can forget trying to debug on the device. It is very frustrating!
My machine specs are the following:
Windows 7 32-bit
3.24GB RAM
Intel Core 2 Duo 1.86GHz
The compiler has been stuck here for over 10 minutes:
Running build steps for project AppName...
Starting: "c:/nokiaqtsdk/symbian/sdk/bin/qmake.exe" C:/QtProjects/AppName/AppName.pro -r -spec symbian-abld -after OBJECTS_DIR=obj MOC_DIR=moc UI_DIR=ui RCC_DIR=rcc CONFIG+=release
The process "c:/nokiaqtsdk/symbian/sdk/bin/qmake.exe" exited normally.
Starting: "C:/NokiaQtSDK/Symbian/SDK/epoc32/tools/make.exe" release-gcce -w
C:\NokiaQtSDK\Symbian\SDK\epoc32\tools\make.exe: Entering directory `C:/QtProjects/AppName'
bldmake bldfiles
ABLD.BAT build gcce urel
make -r -f "\NokiaQtSDK\Symbian\SDK\EPOC32\BUILD\QtProjects\AppName\EXPORT.make" EXPORT VERBOSE=-s
make[1]: Entering directory `C:/QtProjects/AppName'
Nothing to do
make[1]: Leaving directory `C:/QtProjects/AppName'
make -r -f "\NokiaQtSDK\Symbian\SDK\EPOC32\BUILD\QtProjects\AppName\GCCE.make" MAKEFILE VERBOSE=-s
make[1]: Entering directory `C:/QtProjects/AppName'
make -s -C \QtProjects\AppName-f "MAKEFILE_0Xe001827C.MK" TO_ROOT=..\.. EPOCBLD=\NokiaQtSDK\Symbian\SDK\EPOC32\BUILD\MAKEFILE_0Xe001827C\GCCE TO_BLDINF=..\..\QtProjects\AppNamePLATFORM=GCCE MAKMAKE
perl -S makmake.pl -D \QtProjects\AppName\APPNAME_0Xe001827C GCCE
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(65) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\stdapis\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(66) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\stdapis\sys\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(69) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\oem\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(72) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(73) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\osextensions\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(74) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\osextensions\loc\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(76) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\osextensions\loc\sc\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(77) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\domain\middleware\loc\sc\" not found
WARNING: \QtProjects\AppName\APPNAME_0Xe001827C .MMP(82) : SYSTEMINCLUDE path "\NokiaQtSDK\Symbian\SDK\epoc32\include\osextensions\stdapis\stlport\" not found
MMPFILE "\QtProjects\AppName\APPNAME_0Xe001827C .MMP"
I solved the slow compilation problem as indicated by this thread
http://discussion.forum.nokia.com/forum/showthread.php?196650-Selective-compiling&p=720040&viewfull=1#post720040
I added
SYMBIANBUILD_DEPENDENCYOFF = 1
to the project environment variables (or it could be added to Windows environment variables), and the project compilation was back to speed again.
The solution to set the environment variable 'SYMBIANBUILD_DEPENDENCYOFF = 1' as mentioned above also works for us and can result in much quicker Target (GCCE) build times.
However, be aware that you may often need to perform a full (cleaned) re-build of the source if you have modified header files, and specifically added/removed functions for classes and therefore amended the class interface. This is because using this environment variable prevents the Symbian build tools from scanning your include files for changes.
Manually deleting the relevant *.o object files from your QTSDK\Symbian\SDK\epoc32\BUILD_yourfolder_ is a way to prevent the need for a full rebuild but also ensure that affected code is rebuilt.
I believe the slow speed of the Symbian GCCE builds is due to the legacy ABLD build tools, which should be replaced by the Symbian Build System (SBS v2) soon.
I've had trouble with very slow builds due to ZoneAlarm - switching it off resulting in builds 10x quicker... Worth a try if you have an OS firewall installed.
So cool page, the slow building speed in qt creator make me very very very frustrating, I nearly give up the Qt 4.6.3 and 4.7.3, after add the system variable 'SYMBIANBUILD_DEPENDENCYOFF = 1', it is really amazing, speed back, So thanks!
By the way, there is no speed problem in qt 4.7.4 and the compiler use the sbs not the perl any more.