build · brlcad · Zulip Chat Archive

I already have tcl installed but cmake is complaining I don't have it by looking into /usr/lib instead of /usr/bin where tclsh resides

Sean (Dec 03 2017 at 08:47):

Abhishek Prasad (Dec 03 2017 at 09:24):

Sorry, but I still get the following output after setting export TCL_BIN_PREFIX=/usr/bin:

CMake Error at misc/CMake/BRLCAD_Util.cmake:90 (_message):
  Could not find at least one of Tcl, Itcl or Tk libraries in /usr/lib,
  /usr/lib/itcl4.1.0, and /usr/lib - please specify the parent directory for
  the libraries in the TCL_BIN_PREFIX variable (e.g.  ${TCL_BIN_PREFIX}/lib)

Erik (Dec 03 2017 at 12:53):

@Abhishek Prasad the message says TCL_BIN_PREFIX should contain a dir named "lib" with tcl stuff in it, I'd think you'd want to use /usr as the value if you have /usr/bin/tclsh and /usr/lib/tcl*/ ?

Abhishek Prasad (Dec 03 2017 at 13:56):

Sean (Dec 03 2017 at 16:53):

Sean (Dec 03 2017 at 16:54):

you also shouldn't need to install tcl beforehand - you can use the bundled build (see the INSTALL file)

Abhishek Prasad (Dec 04 2017 at 04:56):

Sean (Dec 04 2017 at 14:43):

Sean (Dec 04 2017 at 14:44):

Sean (Dec 04 2017 at 14:45):

@Abhishek Prasad what cmake command are you running (or how are you running cmake)?

Abhishek Prasad (Dec 04 2017 at 15:45):

mkdir build; cd build

Naseef (Dec 04 2017 at 15:45):

Abhishek Prasad (Dec 04 2017 at 15:46):

export TCL_BIN_PATH='/usr'`
../configure

Abhishek Prasad (Dec 04 2017 at 15:48):

Abhishek Prasad (Dec 04 2017 at 16:01):

Abhishek Prasad (Dec 04 2017 at 16:05):

Abhishek Prasad (Dec 04 2017 at 16:06):

Naseef (Dec 04 2017 at 16:07):

Abhishek Prasad (Dec 04 2017 at 16:11):

Naseef (Dec 04 2017 at 16:11):

Abhishek Prasad (Dec 04 2017 at 16:11):

Naseef (Dec 04 2017 at 16:11):

Abhishek Prasad (Dec 04 2017 at 16:12):

Naseef (Dec 04 2017 at 16:12):

Abhishek Prasad (Dec 04 2017 at 16:12):

Naseef (Dec 04 2017 at 16:12):

Abhishek Prasad (Dec 04 2017 at 16:13):

Naseef (Dec 04 2017 at 16:13):

Sean (Dec 04 2017 at 16:20):

Sean (Dec 04 2017 at 16:21):

this isn't an autotools code any more, so ./configure is just a simple wrapper -- you'll want to run cmake+make on linux/mac/bsd

Sean (Dec 04 2017 at 16:22):

note you can compile in parallel, assuming you have multiple cores: make -jN where N is the number of cores you have (e.g., make -j8)

Naseef (Dec 04 2017 at 16:29):

Sean (Dec 04 2017 at 16:29):

so you can run make -j2 to make it a half hour, maybe even a little more with -j3

Abhishek Prasad (Dec 05 2017 at 04:04):

Sorry, but I got an error: https://pastebin.com/xAtcp71w
And many more related errors on the same snprintf in RB_CKORDER macro.

Rahil Malik (Dec 05 2017 at 09:45):

Abhishek Prasad (Dec 05 2017 at 09:49):

Rahil Malik (Dec 05 2017 at 10:07):

Rahil Malik (Dec 05 2017 at 10:08):

Mitesh (Dec 05 2017 at 11:15):

set PATH="(directory of make.exe)";%PATH%
use the above command to set make in command prompt
and then use make command

Mitesh (Dec 05 2017 at 11:15):

Daniel Rossberg (Dec 05 2017 at 11:18):

Rahil Malik (Dec 05 2017 at 14:51):

Rahil Malik (Dec 05 2017 at 14:52):

Rahil Malik (Dec 05 2017 at 14:54):

because i cannot even get to the cmake as cmake shows error about error in configuration process project files maybe invalid

Daniel Rossberg (Dec 05 2017 at 14:58):

So, starting from a current subversion checkout which errors displays CMake? They are displayed in red colour in the CMake GUI log window section.

Rahil Malik (Dec 05 2017 at 15:00):

After the SVNstep the command line shows some revision 70481 type of Comment. After then i do the Cmake step from Cmake GUI hen i see that in the lo many files shows not found and Failed(Looking for print.h - NOT FOUND).

Rahil Malik (Dec 05 2017 at 15:01):

Daniel Rossberg (Dec 05 2017 at 15:03):

Daniel Rossberg (Dec 05 2017 at 15:04):

What you should first try is to use folders without spaces in their name ("New Folder").

Rahil Malik (Dec 05 2017 at 15:06):

Daniel Rossberg (Dec 05 2017 at 15:07):

I can't see errors in your screen shots. (Near an error you can usually find the word "error".)

Rahil Malik (Dec 05 2017 at 15:08):

Rahil Malik (Dec 05 2017 at 15:09):

Daniel Rossberg (Dec 05 2017 at 15:10):

Rahil Malik (Dec 05 2017 at 15:15):

Daniel Rossberg (Dec 05 2017 at 15:15):

Daniel Rossberg (Dec 05 2017 at 15:18):

Daniel Rossberg (Dec 05 2017 at 15:21):

The INSTALL target would be better, but to do this you had to set a writeable directory in CMake where the installation should go to.

Rahil Malik (Dec 05 2017 at 15:22):

Rahil Malik (Dec 05 2017 at 15:23):

Daniel Rossberg (Dec 05 2017 at 15:27):

No. You have to build the program first. Do you know how to start a build in Visual Studio?

Rahil Malik (Dec 05 2017 at 15:28):

Daniel Rossberg (Dec 05 2017 at 15:30):

Rahil Malik (Dec 05 2017 at 15:30):

, i found the file/folder ALL_BUILD in CmakePredefinedTarget. Now what should i do ?

Rahil Malik (Dec 05 2017 at 15:30):

Rahil Malik (Dec 05 2017 at 15:31):

Daniel Rossberg (Dec 05 2017 at 15:32):

E.g.: right click on the ALL_BUILD target and choose "build" (the first one in the selection?)

Rahil Malik (Dec 05 2017 at 15:42):

Daniel Rossberg (Dec 05 2017 at 15:44):

Rahil Malik (Dec 05 2017 at 15:45):

Rahil Malik (Dec 05 2017 at 15:48):

most of the errors are cannot open include file : 'iostream': No such file/Directory
and cmd exited with code 9009

Rahil Malik (Dec 05 2017 at 15:52):

Severity Code Description Project File Line Suppression State
Error LNK1104 cannot open file '..\..\Debug\lib\liboptical.lib' rtarea G:\binaries\src\rt\LINK 1
Error C1083 Cannot open include file: 'iostream': No such file or directory libgdiam G:\brlcad\src\other\libgdiam\gdiam.cpp 40
Error C1083 Cannot open include file: 'iostream': No such file or directory p2t G:\brlcad\src\other\poly2tri\poly2tri\common\shapes.cc 32
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap G:\brlcad\misc\tools\re2c\code.cc 7
Error C1083 Cannot open include file: 'iostream': No such file or directory p2t G:\brlcad\src\other\poly2tri\poly2tri\sweep\sweep.cc 38
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap g:\brlcad\misc\tools\re2c\substr.h 5
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap G:\brlcad\misc\tools\re2c\main.cc 9
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap G:\brlcad\misc\tools\re2c\actions.cc 4
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap g:\brlcad\misc\tools\re2c\substr.h 5
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap G:\binaries\misc\tools\re2c\re2cParse_bootstrap_parser\parser.yy 12
Error C1083 Cannot open include file: 'iostream': No such file or directory re2c_bootstrap G:\binaries\misc\tools\re2c\scanner.re 3
Error LNK2005 terminate already defined in kill.obj libbu G:\binaries\src\libbu\ucrtd.lib(ucrtbased.dll) 1
Error LNK1169 one or more multiply defined symbols found libbu G:\binaries\Debug\bin\libbu.dll 1
Error MSB6006 "cmd.exe" exited with code 9009. re2c C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets 171
Error C1083 Cannot open include file: 'iostream': No such file or directory base g:\brlcad\src\other\stepcode\src\base\sc_benchmark.h 8
Error MSB6006 "cmd.exe" exited with code 9009. perplex C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets 171
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory ogr_frmt_gtm g:\brlcad\src\other\gdal\ogr\ogrsf_frmts\gtm\gtm.h 33
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory ogr_frmt_gtm g:\brlcad\src\other\gdal\ogr\ogrsf_frmts\gtm\gtm.h 33
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory ogr_frmt_gtm g:\brlcad\src\other\gdal\ogr\ogrsf_frmts\gtm\gtm.h 33
Error C1083 Cannot open include file: 'iostream': No such file or directory ogr_frmt_gtm g:\brlcad\src\other\gdal\ogr\ogrsf_frmts\gtm\gtm.h 33
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory ogr_frmt_gtm g:\brlcad\src\other\gdal\ogr\ogrsf_frmts\gtm\gtm.h 33
Error C1083 Cannot open include file: 'iostream': No such file or directory ogr_frmt_gtm g:\brlcad\src\other\gdal\ogr\ogrsf_frmts\gtm\gtm.h 33
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep G:\brlcad\include\bn\dvec.h 30
Error MSB6006 "cmd.exe" exited with code 9009. express C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets 171
Error C1083 Cannot open include file: 'iostream': No such file or directory frmt_kmlsuperoverlay G:\brlcad\src\other\gdal\frmts\kmlsuperoverlay\kmlsuperoverlaydataset.cpp 37
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory gdal_gcore_obj G:\brlcad\src\other\gdal\gcore\gdal_misc.cpp 44
Error MSB6006 "cmd.exe" exited with code 9009. libwfobj C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets 171
Error LNK1104 cannot open file '..\..\..\..\..\Debug\lib\express.lib' libexppp G:\binaries\src\other\stepcode\src\exppp\LINK 1
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory libbrep g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory stepdai G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory librt g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory stepcore G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory librt g:\brlcad\include\bn\dvec.h 30
Error C1083 Cannot open include file: 'iostream': No such file or directory stepcore G:\brlcad\src\other\stepcode\src\clutils\errordesc.h 18
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error C1083 Cannot open include file: 'iostream': No such file or directory exp2cxx g:\brlcad\src\other\stepcode\src\exp2cxx\complexSupport.h 4
Error LNK1104 cannot open file 'G:\binaries\src\other\gdal\gcore\gdal_gcore_obj.dir\Debug\gdal_misc.obj' gdal (Third Party Libraries\GDAL\gdal) G:\binaries\src\other\gdal\LINK 1
Error C1083 Cannot open include file: 'iostream': No such file

Daniel Rossberg (Dec 05 2017 at 15:55):

Do you have a current svn checkout? E.g. revision 70481 would be to old. Maybe you want to do a svn update now.

Rahil Malik (Dec 05 2017 at 15:56):

oh my god, do i have to repeat all the steps then ? and i did download the latest svn

Rahil Malik (Dec 05 2017 at 15:57):

Daniel Rossberg (Dec 05 2017 at 15:57):

You could do the update and restart the build then. CMake will be called automatically.

Daniel Rossberg (Dec 05 2017 at 15:57):

Rahil Malik (Dec 05 2017 at 15:58):

Rahil Malik (Dec 05 2017 at 16:26):

did the update and the reboot, now when i build it in VS2015 still it shows the same error.. because the iostream as in my system the name of the file is iostream.h and unless its written that way the iostream isn't called . so tried renaming it but removing.h even changes the file type which it shouldn't do..now what do i do ?

Rahil Malik (Dec 05 2017 at 16:27):

i copied and pasted the iostream.h in all relatable files of the brl cad now i get only 511 errors which still inlcude the iostream error

Rahil Malik (Dec 05 2017 at 16:29):

Daniel Rossberg (Dec 05 2017 at 16:31):

Everything you did sounds like a very bad idea :(
First, you must not change anything in your Visual Studio installation, where the iostream header belongs to. If you did and you don't know exactly how to undo it you have to deinstall and reinstall Visual Studio.

Rahil Malik (Dec 05 2017 at 16:31):

Daniel Rossberg (Dec 05 2017 at 16:31):

Rahil Malik (Dec 05 2017 at 16:32):

my VS searches for iostream.h but the file includes "iostream" which results in the error. As i have faced the trouble before

Daniel Rossberg (Dec 05 2017 at 16:34):

Rahil Malik (Dec 05 2017 at 16:40):

Daniel Rossberg (Dec 05 2017 at 16:50):

Rahil Malik (Dec 05 2017 at 16:53):

So, now i hide the extensions so the name is iostream but i still get the same error. so do you know where does the projects searh for the header files ?

Rahil Malik (Dec 05 2017 at 16:59):

Daniel Rossberg (Dec 05 2017 at 18:30):

It sound's for me like you have heavily damaged your Visual Studio installation. At least it is in an unknown condition. And with this I can't help.

Sean (Dec 05 2017 at 19:01):

@Abhishek Prasad that error is awesome... what compiler was that (version) .. if you fix the build, I’ll make a GCI task for it

Naseef (Dec 05 2017 at 19:05):

Sean (Dec 05 2017 at 19:07):

@Rahil Malik it sounds like you’ve broken your visual studio installation if it can’t find iostream... or you misread something else earlier in the build process, then took some wrong step

Sean (Dec 05 2017 at 19:08):

Sean (Dec 05 2017 at 19:11):

I suggest you reinstall msvc, delete any brlcad checkout you have, including any build dir you made and start fresh — paste a screenshot after you do that, and after a new scan trunk checkout

Abhishek Prasad (Dec 06 2017 at 05:31):

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (GCC)

Abhishek Prasad (Dec 06 2017 at 06:01):

What does struct bu_rb_package do? I am unable to understand its contents properly.

Abhishek Prasad (Dec 06 2017 at 06:07):

Now I read the macro. It seems safe but would provide an incomplete information. I can sure fix this problem.

Sean (Dec 06 2017 at 07:10):

Sean (Dec 06 2017 at 07:11):

Abhishek Prasad (Dec 06 2017 at 07:47):

Sean (Dec 06 2017 at 07:48):

Abhishek Prasad (Dec 06 2017 at 07:48):

Sean (Dec 06 2017 at 07:48):

Abhishek Prasad (Dec 06 2017 at 07:48):

Sean (Dec 06 2017 at 07:48):

"user" in this context is anything that calls that API, code that calls that API

Sean (Dec 06 2017 at 07:49):

Abhishek Prasad (Dec 06 2017 at 07:49):

Sean (Dec 06 2017 at 07:49):

Sean (Dec 06 2017 at 07:50):

Abhishek Prasad (Dec 06 2017 at 07:51):

Abhishek Prasad (Dec 06 2017 at 07:52):

Sean (Dec 06 2017 at 07:52):

sounds like you've not studied data structures yet, which is okay but just understand there will be much confusion and misunderstanding

Sean (Dec 06 2017 at 07:52):

Abhishek Prasad (Dec 06 2017 at 07:54):

Nah. I am IT 3rd year undergrad student in NIT Durgapur, India. So, data structures have already been taught and I've implemented AVL trees too. RB tree seems too confusing to me. Too many coloring goes in there.

Sean (Dec 06 2017 at 07:55):

Sean (Dec 06 2017 at 07:56):

if you've ever used a std::set in c++, they are pretty much always implemented using redblack trees

Sean (Dec 06 2017 at 07:57):

Sean (Dec 06 2017 at 08:00):

Abhishek Prasad (Dec 06 2017 at 08:02):

Yep. Will get to know more about the implementation details now. I am liking it here. :)

Sean (Dec 06 2017 at 08:03):

Abhishek Prasad (Dec 06 2017 at 08:04):

Sean (Dec 06 2017 at 08:05):

yeah, the truncation warnings you mentioned earlier should be easy enough to fix

Sean (Dec 06 2017 at 08:05):

Abhishek Prasad (Dec 06 2017 at 08:06):

Sean (Dec 06 2017 at 08:06):

Abhishek Prasad (Dec 06 2017 at 08:06):

Sean (Dec 06 2017 at 08:06):

just make your change, run svn diff, and post the patch file somewhere (here is fine)

Sean (Dec 06 2017 at 08:06):

Abhishek Prasad (Dec 06 2017 at 08:07):

Sean (Dec 06 2017 at 08:08):

you generally only make branches for significant risky features expected to live for a long time, and you can't make private branches anyways

Abhishek Prasad (Dec 06 2017 at 08:09):

Sean (Dec 06 2017 at 08:09):

imagine pushing after every operation (every commit, every branch, every change) -- that's svn

Sean (Dec 06 2017 at 08:09):

Abhishek Prasad (Dec 06 2017 at 08:09):

Sean (Dec 06 2017 at 08:09):

Sean (Dec 06 2017 at 08:10):

Abhishek Prasad (Dec 06 2017 at 08:10):

Sean (Dec 06 2017 at 08:13):

in many ways, svn is much simpler in use than git as operations and it's generally more desirable to share changes more often and more frequently (the nature of centralized storage encourages this perspective)

Sean (Dec 06 2017 at 08:15):

biggest features currently still missing from svn which are a given with git is the ability to commit "offline" and browse history locally. svn doesn't let you play by yourself for very long before you're expected to tell and share with others.

Sean (Dec 06 2017 at 08:16):

makes different situations more conducive depending on team dynamics and release needs.

Sean (Dec 06 2017 at 08:17):

Abhishek Prasad (Dec 06 2017 at 08:19):

I think I should make some function which would return the length of a format string. For example:

size_t getFormatLength(const char *format, ...) {
    // To be written
}

const char *fmt = "ERROR: Order %d outside 0..%d (nm_orders-1), file %s, line %d\n";
size_t length = getFormatLength(fmt, (o), (t)->rbt_nm_orders - 1, __FILE__, __LINE__);
char buff[length] = {0};
snprintf(buff, length, fmt, (o), (t)->rbt_nm_orders - 1, __FILE__, __LINE__);

Sean (Dec 06 2017 at 08:19):

Sean (Dec 06 2017 at 08:20):

Abhishek Prasad (Dec 06 2017 at 08:20):

Sean (Dec 06 2017 at 08:22):

I agree, but keep some perspective on this particular snippet of code is not of great importance. We could probably just as well delete the debug/error messages

Abhishek Prasad (Dec 06 2017 at 08:22):

char buff[256] = {0};

Abhishek Prasad (Dec 06 2017 at 08:23):

Sean (Dec 06 2017 at 08:23):

there was talk about comparing our redblack implementation against stl_tree.h (stl's redblack) to see how well it performs -- and if it performs faster, deleting ours and just using standard containers

Sean (Dec 06 2017 at 08:23):

Sean (Dec 06 2017 at 08:25):

stack is typically around 8388608 bytes these days ... we can afford 128 more on this ;)

Sean (Dec 06 2017 at 08:26):

Abhishek Prasad (Dec 06 2017 at 08:53):

Abhishek Prasad (Dec 06 2017 at 08:55):

And what is it with tabs? Is it chosen or we just have to follow because it was previously used?

Rahil Malik (Dec 06 2017 at 14:03):

i uninstalled the vs 2015 and updates and installed VS 2017 and then used cmake to configure and generate the VS 2017 Bui;d files

Rahil Malik (Dec 06 2017 at 14:14):

I simpply uninstalled VS2015 and installed VS2017 and till now it doesnt show any of the iostream error

Rahil Malik (Dec 06 2017 at 14:29):

Rahil Malik (Dec 06 2017 at 14:35):

Daniel Rossberg (Dec 06 2017 at 14:35):

In your build directory there is a Debug or Release directory. And, in this there is a bin directory with a mged.ex. Start it.

Rahil Malik (Dec 06 2017 at 14:36):

Rahil Malik (Dec 06 2017 at 14:38):

Daniel Rossberg (Dec 06 2017 at 14:40):

Rahil Malik (Dec 06 2017 at 14:49):

1>------ Build started: Project: multiconfig_path, Configuration: Debug Win32 ------
1>Generating CMakeTmp/CURRENT_PATH/Debug.done
2>------ Build started: Project: timestamp, Configuration: Debug Win32 ------
2>
2>Build Time: Wed Dec 6 19:30:06 2017
2>
3>------ Build started: Project: regex, Configuration: Debug Win32 ------
4>------ Build started: Project: zlib, Configuration: Debug Win32 ------
5>------ Build started: Project: lemon, Configuration: Debug Win32 ------
6>------ Build started: Project: libgdiam, Configuration: Debug Win32 ------
3>regcomp.c
3>regerror.c
3>regexec.c
3>regfree.c
3>Generating Code...
5>lemon.c
3> Creating library G:/2k17 man/Debug/lib/regex.lib and object G:/2k17 man/Debug/lib/regex.exp
3>regex.vcxproj -> G:\2k17 man\Debug\bin\regex.dll
7>------ Build started: Project: libbu, Configuration: Debug Win32 ------
4>adler32.c
4>compress.c
4>crc32.c
4>deflate.c
4>gzclose.c
4>gzlib.c
4>gzread.c
4>gzwrite.c
5>lemon.vcxproj -> G:\2k17 man\Debug\bin\lemon.exe
8>------ Build started: Project: lz4, Configuration: Debug Win32 ------
4>inflate.c
4>infback.c
6>gdiam.cpp
4>inftrees.c
8>lz4.c
8>lz4frame.c
4>inffast.c
4>trees.c
4>uncompr.c
4>zutil.c
4>Generating Code...
8>lz4hc.c
8>xxhash.c
7>time64.c
7>affinity.c
8>Generating Code...
4> Creating library G:/2k17 man/Debug/lib/zlib.lib and object G:/2k17 man/Debug/lib/zlib.exp
4>zlib.vcxproj -> G:\2k17 man\Debug\bin\zlib1.dll
6> Creating library G:/2k17 man/Debug/lib/libgdiam.lib and object G:/2k17 man/Debug/lib/libgdiam.exp
9>------ Build started: Project: openNURBS, Configuration: Debug Win32 ------
8> Creating library G:/2k17 man/Debug/lib/liblz4.lib and object G:/2k17 man/Debug/lib/liblz4.exp
6>libgdiam.vcxproj -> G:\2k17 man\Debug\bin\libgdiam.dll
8>lz4.vcxproj -> G:\2k17 man\Debug\bin\liblz4.dll
10>------ Build started: Project: tkstub, Configuration: Debug Win32 ------
11>------ Build started: Project: libvds, Configuration: Debug Win32 ------
9>opennurbs_basic.cpp
11>build.c
10>tkStubInit.c
11>cluster.c
11>dynamic.c
11>render.c
11>util.c
11>file.c
11>Generating Code...
11> Creating library G:/2k17 man/Debug/lib/libvds.lib and object G:/2k17 man/Debug/lib/libvds.exp
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20062): error C2059: syntax error: 'constant'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20074): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20075): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20076): error C2143: syntax error: missing '{' before '*'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20084): error C2061: syntax error: identifier 'IMAGE_POLICY_ENTRY'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20085): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20086): error C2143: syntax error: missing '{' before '*'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1126): error C2059: syntax error: 'constant'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1128): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1250): error C2059: syntax error: 'constant'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1252): error C2059: syntax error: '}'
11>libvds.vcxproj -> G:\2k17 man\Debug\bin\libvds.dll
12>------ Build started: Project: tinycthread, Configuration: Debug Win32 ------
10>tkStubLib.c
12>tinycthread.c
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20062): error C2059: syntax error: 'constant'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20074): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20075): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20076): error C2143: syntax error: missing '{' before '*'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20084): error C2061: syntax error: identifier 'IMAGE_POLICY_ENTRY'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20085): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20086): error C2143: syntax error: missing '{' before '*'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1126): error C2059: syntax error: 'constant'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1128): error C2059: syntax error: '}'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1250): error C2059: syntax error: 'constant'
10>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1252): error C2059: syntax error: '}'
10>ttkStubInit.c
10>ttkStubLib.c
10>Done building project "tkstub.vcxproj" -- FAILED.
13>------ Build started: Project: tclstub, Configuration: Debug Win32 ------
12> Creating library G:/2k17 man/Debug/lib/libtinycthread.lib and object G:/2k17 man/Debug/lib/libtinycthread.exp
13>tclStubLib.c
12>tinycthread.vcxproj -> G:\2k17 man\Debug\bin\libtinycthread.dll
14>------ Build started: Project: genfiles, Configuration: Debug Win32 ------
15>------ Build started: Project: p2t, Configuration: Debug Win32 ------
13>LINK : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
13>tclstub.vcxproj -> G:\2k17 man\Debug\lib\tclstub.lib
16>------ Build started: Project: re2c_bootstrap, Configuration: Debug Win32 ------
7>argv.c
7>avs.c
16>[LEMON][re2cParse_bootstrap] Building parser with G:/2k17 man/Debug/bin/lemon
7>b64.c
7>backtrace.c
16>Generating re2cParse_bootstrap_parser/bootstrap_parser.cc
16>Generating re2cParse_bootstrap_parser/bootstrap_parser_tokens.h
16>code.cc
7>badmagic.c
7>bitv.c
7>bomb.c
7>booleanize.c
7>brlcad_path.c
16>dfa.cc
7>cmd.c
9>opennurbs_brep_changesrf.cpp
7>cmdhist.c
16>main.cc
7>color.c
17>------ Build started: Project: png, Configuration: Debug Win32 ------
7>convert.c
7>crashreport.c
7>ctype.c
17>png.c
7>dirent.c
16>actions.cc
9>opennurbs_brep_kinky.cpp
7>datetime.c
16>substr.cc
17>pngerror.c
7>dlfcn.c
7>Generating Code...
17>pngget.c
7>Compiling...
16>translate.cc
7>encode.c
7>endian.c
7>env.c
17>pngmem.c
7>escape.c
7>fchmod.c
17>pngpread.c
16>mbo_getopt.cc
9>opennurbs_x.cpp
7>fgets.c
7>file.c
16>bootstrap_parser.cc
7>fnmatch.c
17>pngread.c
7>getcwd.c
7>gethostname.c
17>pngrio.c
7>getopt.c
16>scanner.cc
7>globals.c
7>hash.c
17>pngrtran.c
7>heap.c
9>opennurbs_3dm_attributes.cpp
7>hist.c
7>hook.c
7>htond.c
7>htonf.c
17>pngrutil.c
7>interrupt.c
7>kill.c
16>Generating Code...
17>pngset.c
7>Generating Code...
7>Compiling...
7>lex.c
7>linebuf.c
17>pngtrans.c
7>list.c
9>opennurbs_3dm_properties.cpp
7>log.c
7>magic.c
7>malloc.c
17>pngwio.c
16>re2c_bootstrap.vcxproj -> G:\2k17 man\Debug\bin\re2c_bootstrap.exe
18>------ Build started: Project: tcl, Configuration: Debug Win32 ------
7>mappedfile.c
18>regcomp.c
17>pngwrite.c
7>mime.c
17>pngwtran.c
7>mread.c
18>regexec.c
9>opennurbs_3dm_settings.cpp
7>observer.c
17>pngwutil.c
18>regfree.c
18>regerror.c
17>Generating Code...
7>opt.c
18>tclAlloc.c
7>parallel.c
18>tclAsync.c
17> Creating library G:/2k17 man/Debug/lib/libpng16d.lib and object G:/2k17 man/Debug/lib/libpng16d.exp
7>parse.c
7>path.c
17>png.vcxproj -> G:\2k17 man\Debug\bin\libpng16d.dll
19>------ Build started: Project: tk, Configuration: Debug Win32 ------
7>printb.c
18>tclBasic.c
7>process.c
19>tk3d.c
7>progname.c
9>opennurbs_annotation.cpp
19>tkArgv.c
18>tclBinary.c
19>tkAtom.c
7>ptbl.c
19>tkBind.c
7>redblack.c
18>tclCkalloc.c
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20062): error C2059: syntax error: 'constant'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20074): error C2059: syntax error: '}'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20075): error C2059: syntax error: '}'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20076): error C2143: syntax error: missing '{' before '*'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20084): error C2061: syntax error: identifier 'IMAGE_POLICY_ENTRY'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20085): error C2059: syntax error: '}'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20086): error C2143: syntax error: missing '{' before '*'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1126): error C2059: syntax error: 'constant'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1128): error C2059: syntax error: '}'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1250): error C2059: syntax error: 'constant'
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h(1252): error C2059: syntax error: '}'
7>realpath.c
19>tkBitmap.c
18>tclClock.c
19>tkButton.c
7>Generating Code...
18>tclCmdAH.c
7>Compiling...
7>semaphore.c
19>tkCanvArc.c
19>tkCanvBmap.c
7>sha1.c
18>tclCmdIL.c
7>simd.c
19>tkCanvImg.c
7>sort.c
7>sscanf.c
19>tkCanvLine.c
9>opennurbs_annotation2.cpp
7>scan.c
18>tclCmdMZ.c
19>tkCanvPoly.c
7>str.c
7>temp.c
19>tkCanvPs.c
18>tclCompCmds.c
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20062): error C2059: syntax error: 'constant'
7>units.c
19>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h(20074): error C2059: syntax error: '}'
19>C:\Program Files (x86)\Windows Kits\10\Include\

Sean (Dec 06 2017 at 15:10):

Sean (Dec 06 2017 at 15:11):

Rahil Malik (Dec 06 2017 at 15:15):

Abhishek Prasad (Dec 06 2017 at 15:38):

Getting errors /usr/lib/libQt5Gui.so.5.9.3: undefined reference to 'png_get_channels@PNG16_0' and more. Isn't cmake using -lpng?

Rahil Malik (Dec 06 2017 at 15:41):

Abhishek Prasad (Dec 06 2017 at 15:42):

A way to point to an existing library on the system, here it is the png manipulation library that is being used by Qt5Gui.

Abhishek Prasad (Dec 06 2017 at 16:58):

[ 55%] Linking C executable ../../bin/btclsh
/usr/bin/ld: warning: librt.so.1, needed by /usr/lib/libsystemd.so.0, may conflict with librt.so.20
/usr/lib/libQt5Gui.so.5.9.3: undefined reference to `png_set_interlace_handling@PNG16_0'
/usr/lib/libQt5Gui.so.5.9.3: undefined reference to `png_set_IHDR@PNG16_0'

Abhishek Prasad (Dec 06 2017 at 16:59):

Abhishek Prasad (Dec 06 2017 at 18:04):

Abhishek Prasad (Dec 07 2017 at 04:07):

Rahil Malik (Dec 07 2017 at 06:20):

In the first step where i have to download the source code through svn, this thing came up and i said accept it permanently IS this the problem ?Is-this-wrong.png

Abhishek Prasad (Dec 07 2017 at 06:44):

Rahil Malik (Dec 07 2017 at 06:45):

Abhishek Prasad (Dec 07 2017 at 06:46):

My opinion is no. Because certificates may change from time to time as they have expiry dates.

Abhishek Prasad (Dec 07 2017 at 06:47):

Rahil Malik (Dec 07 2017 at 06:48):

Rahil Malik (Dec 07 2017 at 07:14):

At the end o the cmd after the svn step this is displayed "Checked out revision 70507."

Rahil Malik (Dec 07 2017 at 07:29):

Should i change the Location of Cmake_Install_Prefix ?? after Cmake Configure ???

Rahil Malik (Dec 07 2017 at 07:31):

Daniel Rossberg (Dec 07 2017 at 07:32):

This variable points to the installation folder. It's set to a default location. If you don't like it and want to have it somewhere else change the value.

Rahil Malik (Dec 07 2017 at 07:33):

I have source code and binary in different hard drive but this is in the C drive . So now ??

Daniel Rossberg (Dec 07 2017 at 07:35):

The source code, build directory, and installation can be all on different drives. Set it up as it fits you best.

Sean (Dec 07 2017 at 07:53):

@Abhishek Prasad BRL-CAD uses a very recent version of libpng with is incompatible with previous versions... that makes it a royal pain in the butt to get system-installed things liking correctly

Sean (Dec 07 2017 at 07:54):

we've been talking about renaming our built-in so that it doesn't conflict, give all symbols a prefix and the lib a different name so we stop having conflicts

Sean (Dec 07 2017 at 08:00):

Sean (Dec 07 2017 at 08:02):

It's okay to accept it temporarily or "permanently". Temporarily just means it will tell you about that certificate every time. Permanently means it won't tell you again ... until the certificate changes.

Rahil Malik (Dec 07 2017 at 08:02):

Sean (Dec 07 2017 at 08:02):

Rahil Malik (Dec 07 2017 at 08:03):

Rahil Malik (Dec 07 2017 at 08:04):

I ran svn command in another drive .. thats all and didn't change the Cmake_Install_Prefix

Sean (Dec 07 2017 at 08:06):

Sean (Dec 07 2017 at 08:07):

Rahil Malik (Dec 07 2017 at 08:09):

Sean (Dec 07 2017 at 08:10):

Rahil Malik (Dec 07 2017 at 08:10):

in cmake I selected the source than an empty oflder for the binaries to be built in and then i configured selected VS 2017 and use native compilers(the default or the first option)

Rahil Malik (Dec 07 2017 at 08:11):

Sean (Dec 07 2017 at 08:11):

Rahil Malik (Dec 07 2017 at 08:11):

Sean (Dec 07 2017 at 08:13):

Rahil Malik (Dec 07 2017 at 08:14):

Sean (Dec 07 2017 at 08:14):

Rahil Malik (Dec 07 2017 at 08:14):

Btw i saw VS 2017 Debug as win32 so i m trying to reinstall cmake as win32 and then try again

Rahil Malik (Dec 07 2017 at 08:15):

I just uninstalled Cmake i will paste the output as I reinstall and run the Codes again

Sean (Dec 07 2017 at 08:15):

Rahil Malik (Dec 07 2017 at 08:16):

Rahil Malik (Dec 07 2017 at 08:17):

So i am installing the Cmake win32 and trying it again his time everything in 32 bit mode

Rahil Malik (Dec 07 2017 at 08:17):

Rahil Malik (Dec 07 2017 at 08:21):

To install Cmake is the source file or the zip file required or can we just use the .msi file to install Cmake ?

Rahil Malik (Dec 07 2017 at 08:24):

Daniel Rossberg (Dec 07 2017 at 08:25):

Rahil Malik (Dec 07 2017 at 08:26):

Sean (Dec 07 2017 at 08:26):

Sean (Dec 07 2017 at 08:27):

Daniel Rossberg (Dec 07 2017 at 08:27):

In VS you see the compiler version you have selected when you started CMake the first time for your project.

Sean (Dec 07 2017 at 08:28):

rather, your cmake WAS fine .. considering you uninstalled it. so please reinstall it, run it again, and post the entire log output

Rahil Malik (Dec 07 2017 at 08:28):

Sean (Dec 07 2017 at 08:29):

Sean (Dec 07 2017 at 08:30):

you had an error in a system header -- that should only caused by one of two things

Sean (Dec 07 2017 at 08:31):

that said, there have been a TON of build system changes lately that could affect compilation on Windows, so you may need to also try compiling 7.26.4 instead of trunk until things get fixed, if it turns out there's a problem on trunk right now

Jeewal Kunwar (Dec 07 2017 at 08:39):

Jeewal Kunwar (Dec 07 2017 at 08:41):

Sean (Dec 07 2017 at 08:44):

Rahil Malik (Dec 07 2017 at 08:57):

Sean (Dec 07 2017 at 09:03):

Rahil Malik (Dec 07 2017 at 09:03):

Rahil Malik (Dec 07 2017 at 09:04):

Sean (Dec 07 2017 at 09:06):

Rahil Malik (Dec 07 2017 at 09:07):

Right now , I am configuring the source code and after that i will paste the output herre, then i will generrate and post the output again

Sean (Dec 07 2017 at 09:07):

when you run cmake gui, your source cmake directory should be \Users\Batman\brlcad-svn-trunk

Sean (Dec 07 2017 at 09:08):

Sean (Dec 07 2017 at 09:09):

Sean (Dec 07 2017 at 09:12):

alrighty, it's kind of hard to help without a complete picture of what you're doing and now I got to go... I suggest you confirm with someone at each step before you do anything else ...

Rahil Malik (Dec 07 2017 at 09:19):

The C compiler identification is MSVC 19.12.25830.2
The CXX compiler identification is MSVC 19.12.25830.2
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx86/x86/cl.exe
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx86/x86/cl.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx86/x86/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.12.25827/bin/Hostx86/x86/cl.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
Performing Test NOERROR_FLAG_C
Performing Test NOERROR_FLAG_C - Failed
Performing Test NOERROR_FLAG_CXX
Performing Test NOERROR_FLAG_CXX - Failed

* Configuring BRL-CAD Release 7.27.0, Build 20171207 *
***********
Looking for sys/types.h
Looking for sys/types.h - found
Looking for stdint.h
Looking for stdint.h - found
Looking for stddef.h
Looking for stddef.h - found
Check size of void
Check size of void * - done
*************

Could NOT find SHELL_SUPPORTED (missing: SH_EXEC CP_EXEC MV_EXEC RM_EXEC)
Could NOT find LEX (missing: LEX_EXECUTABLE)
Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)

Performing Test PIPE_C_FLAG_FOUND
Performing Test PIPE_C_FLAG_FOUND - Failed
Performing Test PIPE_CXX_FLAG_FOUND
Performing Test PIPE_CXX_FLAG_FOUND - Failed
Performing Test FNO_STRICT_ALIASING_C_FLAG_FOUND
Performing Test FNO_STRICT_ALIASING_C_FLAG_FOUND - Failed
Performing Test FNO_STRICT_ALIASING_CXX_FLAG_FOUND
Performing Test FNO_STRICT_ALIASING_CXX_FLAG_FOUND - Failed
Performing Test FNO_COMMON_C_FLAG_FOUND
Performing Test FNO_COMMON_C_FLAG_FOUND - Failed
Performing Test FNO_COMMON_CXX_FLAG_FOUND
Performing Test FNO_COMMON_CXX_FLAG_FOUND - Failed
Performing Test FEXCEPTIONS_C_FLAG_FOUND
Performing Test FEXCEPTIONS_C_FLAG_FOUND - Failed
Performing Test FEXCEPTIONS_CXX_FLAG_FOUND
Performing Test FEXCEPTIONS_CXX_FLAG_FOUND - Failed
Performing Test FTEMPLATE_DEPTH_128_CXX_FLAG_FOUND
Performing Test FTEMPLATE_DEPTH_128_CXX_FLAG_FOUND - Failed
Performing Test G_C_FLAG_FOUND
Performing Test G_C_FLAG_FOUND - Failed
Performing Test G_CXX_FLAG_FOUND
Performing Test G_CXX_FLAG_FOUND - Failed
Performing Test GGDB3_C_FLAG_FOUND
Performing Test GGDB3_C_FLAG_FOUND - Failed
Performing Test GGDB3_CXX_FLAG_FOUND
Performing Test GGDB3_CXX_FLAG_FOUND - Failed
Performing Test HAVE_INLINE_KEYWORD
Performing Test HAVE_INLINE_KEYWORD - Success
Performing Test WERROR_C_FLAG_FOUND
Performing Test WERROR_C_FLAG_FOUND - Failed
Performing Test HAVE_NORETURN_ATTRIBUTE
Performing Test HAVE_NORETURN_ATTRIBUTE - Failed
Performing Test HAVE_ANALYZER_NORETURN_ATTRIBUTE
Performing Test HAVE_ANALYZER_NORETURN_ATTRIBUTE - Failed
Performing Test HAVE_ALWAYS_INLINE_ATTRIBUTE
Performing Test HAVE_ALWAYS_INLINE_ATTRIBUTE - Failed
Performing Test HAVE_PRINTF12_ATTRIBUTE
Performing Test HAVE_PRINTF12_ATTRIBUTE - Failed
Performing Test HAVE_PRINTF23_ATTRIBUTE
Performing Test HAVE_PRINTF23_ATTRIBUTE - Failed
Performing Test HAVE_SCANF23_ATTRIBUTE
Performing Test HAVE_SCANF23_ATTRIBUTE - Failed
Performing Test QUNUSED_ARGUMENTS_C_FLAG_FOUND
Performing Test QUNUSED_ARGUMENTS_C_FLAG_FOUND - Failed
Performing Test QUNUSED_ARGUMENTS_CXX_FLAG_FOUND
Performing Test QUNUSED_ARGUMENTS_CXX_FLAG_FOUND - Failed

Looking for pthread.h
Looking for pthread.h - not found
Found Threads: TRUE
Performing Test STL_LIB_TEST
Performing Test STL_LIB_TEST - Success
Looking for daemon in bsd
Looking for daemon in bsd - not found
Looking for daemon in c
Looking for daemon in c - not found
Looking for cos in m
Looking for cos in m - not found
Looking for socket in socket
Looking for socket in socket - not found
Looking for gethostbyaddr in nsl
Looking for gethostbyaddr in nsl - not found
Looking for socket in network
Looking for socket in network - not found
Looking for mallopt in c
Looking for mallopt in c - not found
Looking for mallopt in malloc
Looking for mallopt in malloc - not found
Looking for dlopen in dl
Looking for dlopen in dl - not found
Looking for yyless in l
Looking for yyless in l - not found
Performing Test HAVE_TIMESETEVENT
Performing Test HAVE_TIMESETEVENT - Success

Performing Test WORKING_SYS_WAIT
Performing Test WORKING_SYS_WAIT - Failed
Looking for include file dirent.h
Looking for include file dirent.h - not found
Looking for include file arpa/inet.h
Looking for include file arpa/inet.h - not found
Looking for include file direct.h
Looking for include file direct.h - found
Looking for include file dlfcn.h
Looking for include file dlfcn.h - not found
Looking for include file dslib.h
Looking for include file dslib.h - not found
Looking for include file emmintrin.h
Looking for include file emmintrin.h - found
Looking for include file getopt.h
Looking for include file getopt.h - not found
Looking for include file gl/device.h
Looking for include file gl/device.h - not found
Looking for include file gl/glext.h
Looking for include file gl/glext.h - not found
Looking for include file gl/wglext.h
Looking for include file gl/wglext.h - not found
Looking for include file grp.h
Looking for include file grp.h - not found
Looking for include file inttypes.h
Looking for include file inttypes.h - found
Looking for include file io.h
Looking for include file io.h - found
Looking for include file libgen.h
Looking for include file libgen.h - not found
Looking for include file mach/thread_policy.h
Looking for include file mach/thread_policy.h - not found
Looking for include file memory.h
Looking for include file memory.h - found
Looking for include file netdb.h
Looking for include file netdb.h - not found
Looking for include file netinet/in.h
Looking for include file netinet/in.h - not found
Looking for include file poll.h
Looking for include file poll.h - not found
Looking for include file process.h
Looking for include file process.h - found
Looking for include file pthread.h
Looking for include file pthread.h - not found
Looking for include file pthread_np.h
Looking for include file pthread_np.h - not found
Looking for include file pwd.h
Looking for include file pwd.h - not found
Looking for include file rle.h
Looking for include file rle.h - not found
Looking for include file sched.h
Looking for include file sched.h - not found
Looking for include file sgtty.h
Looking for include file sgtty.h - not found
Looking for include file signal.h
Looking for include file signal.h - found
Looking for include file stdlib.h
Looking for include file stdlib.h - found
Looking for include file string.h
Looking for include file string.h - found
Looking for include file strings.h
Looking for include file strings.h - not found
Looking for include file strsafe.h
Looking for include file strsafe.h - found
Looking for include file sys/_ioctl.h
Looking for include file sys/_ioctl.h - not found
Looking for include file sys/cpuset.h
Looking for include file sys/cpuset.h - not found
Looking for include file sys/file.h
Looking for include file sys/file.h - not found
Looking for include file sys/ioctl.h
Looking for include file sys/ioctl.h - not found
Looking for include file sys/ioctl_compat.h
Looking for include file sys/ioctl_compat.h - not found
Looking for include file sys/ipc.h
Looking for include file sys/ipc.h - not found
Looking for include file sys/machd.h
Looking for include file sys/machd.h - not found
Looking for include file sys/mman.h
Looking for include file sys/mman.h - not found
Looking for include file sys/mount.h
Looking for include file sys/mount.h - not found
Looking for include file sys/param.h
Looking for include file sys/param.h - not found
Looking for include file sys/prctl.h
Looking for include file sys/prctl.h - not found
Looking for include file sys/resource.h
Looking for include file sys/resource.h - not found
Looking for include file sys/sched.h
Looking for include file sys/sched.h - not found
Looking for include file sys/select.h
Looking for include file sys/select.h - not found
Looking for include file sys/shm.h
Looking for include file sys/shm.h - not found
Looking for include file sys/socket.h
Looking for include file sys/socket.h - not found
Looking for include file sys/stat.h
Looking for include file sys/stat.h - found
Looking for include file sys/sysctl.h
Looking for include file sys/sysctl.h - not found
Looking for include file sys/sysinfo.h
Looking for include file sys/sysinfo.h - not found
Looking for include file sys/sysmp.h
Looking for include file sys/sysmp.h - not found
Looking for include file sys/time.h
Looking for include file sys/time.h - not found
Looking for include file sys/times.h
Looking for include file sys/times.h - not found
Lookin

Rahil Malik (Dec 07 2017 at 09:21):

I have downloaded brlcad source code in another hard disk(the SVN step).
Then Source folder is the folder where i downloaded the brlcad and then i select an empty folder in the same hard disk to build the binaries

Rahil Malik (Dec 07 2017 at 09:22):

* Configuring BRL-CAD Release 7.27.0, Build 20171207 *
**************
Could NOT find SHELL_SUPPORTED (missing: SH_EXEC CP_EXEC MV_EXEC RM_EXEC)
Could NOT find LEX (missing: LEX_EXECUTABLE)
Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
Could NOT find TIMEZONE (missing: TIMEZONE_DATA_DIR)
Found ZLIB: F:/SImpleton/brlcad/src/other/libz;F:/Amazed/src/other/libz
Found ZLIB: zlib

-------------------- BRL-CAD Release 7.27.0, Build 20171207 --------------------

    Prefix: F:/Amazed
  Binaries: F:/Amazed/bin
 Libraries: F:/Amazed/lib

Flags common to all build configurations:
CFLAGS = /DWIN32 /D_WINDOWS /W3
CXXFLAGS = /DWIN32 /D_WINDOWS /W3 /GR /EHsc
LDFLAGS = /machine:X86 /STACK:10000000 /NOLOGO /STACK:10000000 /NOLOGO

Additional Compilation flags used when building with configuration Debug:
CFLAGS = /MDd /Zi /Ob0 /Od /RTC1
CXXFLAGS = /MDd /Zi /Ob0 /Od /RTC1
LDFLAGS = /debug /INCREMENTAL

Additional Compilation flags used when building with configuration Release:
CFLAGS = /MD /O2 /Ob2 /DNDEBUG
CXXFLAGS = /MD /O2 /Ob2 /DNDEBUG
LDFLAGS = /INCREMENTAL:NO

Compile Tcl ...........................: ON
Compile Tk ............................: ON
Compile Itcl/Itk ......................: ON
Compile Iwidgets ......................: ON
Compile Tkhtml ........................: ON
Compile tkpng .........................: ON
Compile Tktable .......................: ON
Compile libpng ........................: ON
Compile libregex ......................: ON
Compile zlib ..........................: ON
Compile termlib .......................: OFF
Compile Utah Raster Toolkit ...........: ON
Compile openNURBS .....................: ON
Compile STEPcode.......................: ON

OpenGL support (optional) .............: ON
X11 support (optional) ................: OFF
Qt support (optional) .................: OFF
Enable run-time debugging (optional) ..: ON

Build 32/64-bit release ...............: 32BIT (Auto)
Build optimized release ...............: Build Configuration Dependent
Build static libraries ................: ON
Build dynamic libraries ...............: ON
Install example geometry models .......: ON
Generate extra docs ...................: ON (html)

Rahil Malik (Dec 07 2017 at 09:51):

Severity Code Description Project File Line Error C2143 syntax error: missing '{' before '*' Error C2059 syntax error: 'constant' tkstub Error C2059 syntax error: '}' tkstub C:\Program Error C2059 syntax error: '}' tkstub C:\Program Error C2143 syntax error: missing '{' before '*' Error C2061 syntax error: identifier 'IMAGE_POLICY_ENTRY' Error C2059 syntax error: '}' tkstub C:\Program Error C2059 syntax error: 'constant' tkstub Error C2059 syntax error: '}' tkstub C:\Program Error C2059 syntax error: 'constant' tkstub Error C2059 syntax error: '}' tkstub C:\Program Error C2059 syntax error: 'constant' tkstub Error C2059 syntax error: '}' tkstub C:\Program Error C2059 syntax error: '}' tkstub C:\Program Error C2143 syntax error: missing '{' before '*' Error C2061 syntax error: identifier 'IMAGE_POLICY_ENTRY' Error C2059 syntax error: '}' tkstub C:\Program Error C2143 syntax error: missing '{' before '*' Error C2059 syntax error: 'constant' tkstub Error C2059 syntax error: '}' tkstub C:\Program Error C2059 syntax error: 'constant' tkstub Error C2059 syntax error: '}' tkstub C:\Program Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Error C2375 'lrint': redefinition; different linkage Suppression State
tkstub C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20086
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20062
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20074
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20075
tkstub C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20076
tkstub C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20084
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20085
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1126
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1128
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1250
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1252
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20062
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20074
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20075
tkstub C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20076
tkstub C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20084
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20085
tkstub C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\winnt.h 20086
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1126
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1128
C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1250
Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\processthreadsapi.h 1252
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbu C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbn C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbg C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\corecrt_math.h 519
libbg C:\Program Files (x86)\Windows

Rahil Malik (Dec 07 2017 at 09:52):

Rahil Malik (Dec 07 2017 at 11:01):

Abhishek Prasad (Dec 07 2017 at 13:55):

Sean (Dec 07 2017 at 15:35):

@Abhishek Prasad it's neither tab or spaces -- it's a mix of both (indent is 4 spaces, tabs every two indent levels -- every 8 spaces is replaced with a tab), and it's fine for your first task or two if you don't get it right. However, if you're serious about doing tasks, you should figure out how to be consistent with the existing code.

Abhishek Prasad (Dec 07 2017 at 16:01):

Jeff Sieu (Dec 08 2017 at 07:42):

Jeff Sieu (Dec 08 2017 at 07:51):

Sean (Dec 08 2017 at 08:13):

@Abhishek Prasad indent-region should be doing tab conversions already -- what's this change do?

Abhishek Prasad (Dec 08 2017 at 17:18):

indent-region indents code by inserting tabs only if a specific line isn't indented. It doesn't replace spaces that could be converted to tab on an indented line. At least it doesn't happen in my Emacs.

Francisco Fernandes (Dec 10 2017 at 19:53):

Francisco Fernandes (Dec 10 2017 at 20:00):

@Sean I know that you are a mentor, if you don't mind I would like to talk to you for a moment to ask some questions

Mahdi (Dec 10 2017 at 21:46):

Francisco Fernandes (Dec 10 2017 at 21:49):

Sean (Dec 11 2017 at 06:37):

Jeff Sieu (Dec 12 2017 at 14:25):

I seem to be getting the same problem with building as @Rahil Malik above. The error messages returned are exactly the same.

Jeff Sieu (Dec 12 2017 at 14:29):

Daniel Rossberg (Dec 12 2017 at 14:34):

It's the first time I see this. winnt.h is a Visual Studio system header, so don't touch this!
You have Visual Studio 2017 on Windows 10?
Could anybody compile BRL-CAD with this combination or is it a new one?

Jeff Sieu (Dec 12 2017 at 14:37):

Yeah, it's Visual Studio 2017 on Windows 10. Was the latest version of Visual Studio that the compilation worked on older than this?

Daniel Rossberg (Dec 12 2017 at 14:39):

I don't know. I've 2013. I'm sure 2015 is tested too, but I don't know the status of 2017.

Jeff Sieu (Dec 13 2017 at 17:15):

wow, after 2 days of trying to build on windows i switched to linux and it just worked like that

Jeff Sieu (Dec 13 2017 at 17:37):

Jeff Sieu (Dec 13 2017 at 17:38):

Jeff Sieu (Dec 13 2017 at 17:48):

Jeff Sieu (Dec 13 2017 at 18:00):

Strange, I get this error when trying to build from SVN but not when from sourceforge

Daniel Rossberg (Dec 13 2017 at 20:26):

I don't ask what's the difference between svn and sourceforge now, but you should try to run CMake with BRLCAD_ENABLE_STRICT=OFF set.

Jeff Sieu (Dec 15 2017 at 06:34):

Daniel Rossberg (Dec 15 2017 at 08:15):

I think svn is currently 7.27.0, but however you seem to haven't installed the X11 developer libraries. See https://brlcad.org/wiki/Compiling for a list of some necessary additional (Debian) packages.

Jeff Sieu (Dec 15 2017 at 14:16):

Oh oops, I had overlooked that, my bad. The build is successful now. Thanks for your help!

Sean (Dec 19 2017 at 01:32):

jeff, it also looks like you're compiling strict, which you could turn off for now (-DBRLCAD_ENABLE_STRICT=OFF)

Sean (Dec 19 2017 at 01:32):

Jeff Sieu (Dec 19 2017 at 03:57):

Yeah, I was. after installing the x11 libraries it compiles with or without strict. For the current task, I kept it on though. Trying to ensure that my code will be consistent with coding style defined

Sean (Dec 19 2017 at 05:14):

Siddharth (Dec 20 2017 at 06:26):

Siddharth (Dec 20 2017 at 06:45):

Can anyone please help me out? How do I fix this error, even the GUI version of cmake doesn't work Capture.PNG

Siddharth (Dec 20 2017 at 06:55):

Sean (Dec 20 2017 at 07:12):

welcome siddharth -- you'll need to more specific to get help you with your build error ... post some of your build log and the steps you ran before compiling (e.g., you cmake settings).

Sean (Dec 20 2017 at 07:15):

are you actually running windows 10? you selected a cmake target for that which probably isn't what you need -- you need to specify msvc 2015 output files. you don't need to reinstall cmake, but you do probably need to re-run it fresh and look for the oup

Sean (Dec 20 2017 at 07:15):

Adhyan Dhull (Dec 21 2017 at 09:54):

Siddharth (Dec 21 2017 at 10:04):

Hey Mentor, I have a doubt, in the task 'LibreCAD - Design a new onepager website' can we add something extra like an image gallery or something?

Naseef (Dec 22 2017 at 11:35):

@Adhyan Dhull
You can complete other task without claiming them. Task won't go away very soon unless it's really popular.
BTW This topic is about building BRL-CAD, please ask your questions in #Google Code-in next time. :)

Daniel Rossberg (Mar 01 2018 at 18:27):

In file included from brlcad/src/other/stepcode/src/clstepcore/collect.cc:14:0:
/brlcad/src/other/stepcode/src/clstepcore/complexSupport.h:21:31: error: ‘off_t’ has not been declared
 extern "C" int fseeko(FILE *, off_t, int);
                               ^~~~~
brlcad/src/other/stepcode/src/clstepcore/complexSupport.h:22:12: error: ‘off_t’ does not name a type
 extern "C" off_t ftello(FILE *);

Sean (Mar 02 2018 at 05:17):

yeah, sorry about that -- the last bits of the strict c90 still need to be committed, but sourceforge has been down today

Sean (Mar 02 2018 at 05:18):

@Daniel Rossberg i have a fix for that as soon as sf.net is back up; otherwise the quick workaround fix is to just add typedef long off_t;

Saran Narayan (Mar 14 2018 at 13:37):

[ 82%] Linking C executable rt_pattern
../../../lib/librt.so.20.0.1: undefined reference to `_tthread_timespec_get'
collect2: error: ld returned 1 exit status
src/librt/tests/CMakeFiles/rt_pattern.dir/build.make:108: recipe for target 'src/librt/tests/rt_pattern' failed
make[2]: *** [src/librt/tests/rt_pattern] Error 1
CMakeFiles/Makefile2:15249: recipe for target 'src/librt/tests/CMakeFiles/rt_pattern.dir/all' failed
make[1]: *** [src/librt/tests/CMakeFiles/rt_pattern.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
../../../lib/librt.so.20.0.1: undefined reference to `_tthread_timespec_get'
collect2: error: ld returned 1 exit status
src/librt/tests/CMakeFiles/rt_ssi.dir/build.make:108: recipe for target 'src/librt/tests/rt_ssi' failed
make[2]: *** [src/librt/tests/rt_ssi] Error 1
CMakeFiles/Makefile2:15201: recipe for target 'src/librt/tests/CMakeFiles/rt_ssi.dir/all' failed
make[1]: *** [src/librt/tests/CMakeFiles/rt_ssi.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

Sean (Mar 14 2018 at 13:54):

not an error I've seen before but it's related to c++11 and c90 ... run "make VERBOSE=1" and see what flags it's using

Sean (Mar 14 2018 at 13:55):

Saran Narayan (Mar 14 2018 at 15:04):

Sean (Mar 15 2018 at 02:12):

Try manually fixing it first. You can copy-paste the compile line verbose showed from the right directory. Make sure it errors as expected, then try adding -ltinycthread or ../../lib/libtiny... etc.

Daniel Rossberg (Mar 18 2018 at 16:36):

I'm experiencing a tinycthread related issue as well, with as useful error messages as expected ‘struct timespec *’ but argument is of type ‘struct timespec *’ in src/librt/primitives/bot/gct_decimation/auxiliary/mmthread.h. (gcc 6.3.0, CMake config from scratch)

Daniel Rossberg (Mar 18 2018 at 16:37):

Looks like a conflict between declarations in tinycthread and the standard headers.

Sean (Mar 20 2018 at 05:44):

@Daniel Rossberg you are? we've been talking about that one trying to find a platform that reproduces it. where do you see it? is it because -ltinycthread is getting detected as system-avail or missing from linker line or literally just the useful errors..?

Daniel Rossberg (Mar 20 2018 at 09:51):

@Sean I'm working with Debian stretch.
The error I experience is a compilation error. A work around is to put the definition of timespec before the include of tinycthread.h in src/librt/primitives/bot/gct_decimation/auxiliary/mmthread.h.

Then, I got the linker error Sharan and Fatema wrote about. For me, it looks like the tinycthread library is in fact missing the _tthread_timespec_get function, because it's compiled with different compiler settings then the BRL-CAD libraries (-std=gnu99 for tinycthread and -std=c90 for BRL-CAD binaries).

Sean (Mar 21 2018 at 00:59):

ah, okay @Daniel Rossberg thanks for the info -- we've been trying to find a platform to reproduce it. it looks like a cmake test is failing when it shouldn't, which is cascading to unintended tinycthread issues. in this particular case, it looks like it may make more sense to just rewrite the bit of timer code in gct_decimation since it doesn't need to use tinycthread

Daniel Rossberg (Mar 22 2018 at 18:36):

Peter Pronai (Mar 26 2018 at 00:30):

As of r70851 I can't get the debug configuration to build. It worked a few days ago but now it complains about a redefinition of struct timespec in mmthread.h:52:8 and -Wno-c99-extensions being an unrecognized option.

System info: 64 bit Arch Linux, the compiler is gcc, bundled libs is on, no other cmake options given.

Sean (Mar 26 2018 at 05:30):

@Peter Pronai make sure you have the latest version of cmake (and delete your build dir before retrying). it sounds like invalid cached values causing problems.

Peter Pronai (Mar 26 2018 at 15:10):

I did a clean build with cmake -DBRLCAD_BUNDLED_LIBS=ON but it failed in the same way. I'm also running another build whose flags are more closely based on the PKGBUILD, except with debug/flags/strict/warnings turned on.

Peter Pronai (Mar 26 2018 at 20:30):

Sean (Mar 26 2018 at 20:49):

hearing things fail without reading logs is kind of useless. you should read them and try to decipher why they failed. you can post the failure and help if you're not used to doing that.

Sean (Mar 26 2018 at 20:49):

error messages are not black magic. they typically say precisely why it failed. ;)

Peter Pronai (Mar 26 2018 at 21:31):

@Sean it was the exact same error both times, redefinition of struct timespec and unrecognized command line option -Wno-c11-extensions :disappointed:
I would dig into it further but right now I have to finish my GSoC proposal.

Peter Pronai (Mar 26 2018 at 21:32):

I mean, I could do the obvious thing and comment the definition out but that wouldn't really fix it and it's not immediately useful for me for my task at hand, so... :shrug:

Sean (Mar 27 2018 at 01:08):

you're right that wouldn't fix it, but that's also a shallow analysis. the question to investigate would be why are there two definitions (where are they coming from). one is almost certainly a mistake.

Sean (Mar 27 2018 at 01:08):

I believe the -Wno-c11-extensions flag is coming directly from cmake which is why I said make sure you're using the latest cmake. You didn't say what version you're running.

Peter Pronai (Mar 27 2018 at 01:12):

Sorry, I left that out. Well, it's Arch, so every package is usually the latest stable version, but to be safe.... cmake --version says 3.10.3, and that's the latest according to cmake.org.

Naseef (Mar 29 2018 at 06:51):

Any plans on moving BRL-CAD to Github in the future? Sourceforge has a lot of ads and the UI is a lot better in Github. Migrating from SVN to Git won't be a big problem right?

Sean (Mar 30 2018 at 16:51):

Some of our stuff is already on github, and yes there are plans to move more. We have the worlds oldest repo, so it's going to take some effort to make sure everything is preserved correctly. Moving to any new repo is always a problem as we tend to break them or find things they don't support (which has already happened).

Naseef (Mar 30 2018 at 18:56):

Peter Pronai (Apr 04 2018 at 00:23):

Ok so I had some more time to look into the compilation errors (redefinition of struct timespec in mmthread.h) annnnd, well, there just needs to be a HAVE_STRUCT_TIMESPEC definition somewhere, but I'm not yet sure where to put that? I guess there should be a test somewhere in the cmake config, but I have been avoiding cmake in my personal projects until now. (don't need all that extra complexity)

So, should I keep investigating or should I leave it someone who has a better understanding of all the cross platform nuances?

Sean (Apr 04 2018 at 12:21):

@Peter Pronai are you on a trunk checkout? That issue may be fixed. but the place to put that is ...nowhere by you. That should be detected and defined by cmake, as you note. It's not extra complexity when you need to build a lot and need to build everywhere. But that said, it may be all fixed.

Peter Pronai (Apr 06 2018 at 00:16):

...oh heck. Ok, I misunderstood how git svn fetch works. I got it building last night. >_>

Peter Pronai (Apr 06 2018 at 00:18):

The following tests FAILED:
      1 - NOTE: some 'test' tests are expected to fail, 'regress' must pass (Failed)
    788 - regress-solids (Failed)
    792 - regress-weight (Failed)
    816 - regress-rtwizard-rtwiz_m35_A (Timeout)
    817 - regress-rtwizard-rtwiz_m35_B (Timeout)
    818 - regress-rtwizard-rtwiz_m35_C (Timeout)
    819 - regress-rtwizard-rtwiz_m35_D (Timeout)
    820 - regress-rtwizard-rtwiz_m35_E (Timeout)
    821 - regress-rtwizard-rtwiz_m35_F (Timeout)
    822 - regress-rtwizard-rtwiz_m35_edge_only (Timeout)
    823 - regress-rtwizard-rtwiz_m35_edge_only_color (Timeout)

Sean (Apr 06 2018 at 14:23):

The following tests FAILED:
1 - NOTE: some 'test' tests are expected to fail, 'regress' must pass (Failed)
788 - regress-solids (Failed)
792 - regress-weight (Failed)
816 - regress-rtwizard-rtwiz_m35_A (Timeout)
817 - regress-rtwizard-rtwiz_m35_B (Timeout)
818 - regress-rtwizard-rtwiz_m35_C (Timeout)
819 - regress-rtwizard-rtwiz_m35_D (Timeout)
820 - regress-rtwizard-rtwiz_m35_E (Timeout)
821 - regress-rtwizard-rtwiz_m35_F (Timeout)
822 - regress-rtwizard-rtwiz_m35_edge_only (Timeout)
823 - regress-rtwizard-rtwiz_m35_edge_only_color (Timeout)

Not sure how bad that is, it doesn't seem to be anything horrible.

Well it tells you right there... the regress tests must pass and you have a whole list of regress-* tests that have failed. So, it's not good.

Daniel Rossberg (Apr 06 2018 at 15:59):

You can look at <your build directory>/Testing/Temporary to get an idea about what went wrong and how to repeat single tests.

Jaipal Singh (Apr 06 2018 at 17:27):

Hey guys, what does the point_t data type signify? One comment in the code says, it /* will contain our hit point coordinate */. What kind of values can it take?

Daniel Rossberg (Apr 06 2018 at 17:37):

Jaipal Singh (Apr 06 2018 at 18:36):

Jaipal Singh (Apr 06 2018 at 18:44):

Would it be fair to consider that the centroid of a metaball would be the average of all it's vertices?

Jaipal Singh (Apr 06 2018 at 18:49):

From what I gather, a metaball is two sphere objects drawn around two control points. So could the mid-point between these two points could be the centroid for the object?

Sean (Apr 06 2018 at 20:31):

What you might be able to do is evaluate the surface to an approximately (call the rt_*_tess() callback) and calculate the centroid of that result. Otherwise, you need to figure out which of the metaballs are connected, and how big they are.

Sean (Apr 06 2018 at 20:33):

Not a sphere when those points are in proximity. That said, two points is a degenerate case -- it's the mid point if they are weighted equally.

starseeker (Apr 07 2018 at 01:41):

starseeker (Apr 07 2018 at 01:42):

Jaipal Singh (Apr 07 2018 at 05:37):

@Sean , rt_*_tess() is used for generates a polygon mesh around the primitive?
Also, rt_metaball_tess() is not implemented, would I have to implement it from scratch or is there some sort of boiler plate code I can use?

Jaipal Singh (Apr 07 2018 at 05:37):

Peter Pronai (Apr 07 2018 at 20:03):

I ran the tests again and only one failed (the one that prints that warning thing). I think the timeout was caused by a) heavy load by other applications b) my laptop going to sleep. Not sure about the other two regress tests.

Sean (Apr 09 2018 at 16:07):

That's quite possible. Testing can kick off a ton of processes and exceed system limits. If it's not repeatable, then that's probably not you're doing.

Peter Pronai (Apr 26 2018 at 19:01):

Just out of curiosity, has anyone tried building (an old version of) BRL-CAD on Plan 9?

Sean (Apr 26 2018 at 19:02):

Sean (Apr 26 2018 at 19:03):

Peter Pronai (Apr 26 2018 at 19:05):

@Sean hmmmmm, I'm tempted to try to do it on my new CPU server but... probably too much work rn. >_>

Sean (Apr 26 2018 at 19:05):

Sean (Apr 26 2018 at 19:06):

the only hard parts might be the newest c++11 bits, but those can be turned off easily enough

Peter Pronai (Apr 26 2018 at 19:11):

starseeker (Apr 27 2018 at 02:08):

Fair warning though, after 7.28.0 we'll almost certainly be introducing more C++11 - right now things should build C90/C++98, but that won't last.

starseeker (Apr 27 2018 at 02:10):

@Peter Pronai Another interesting alternative OS platform to explore building on might be Haiku, if you're into that sort of thing

Peter Pronai (Apr 27 2018 at 10:12):

@starseeker I have booted Haiku up a few times but I'm not into all that GUI stuff :/
Plus I know Haiku already has gcc so I suspect it should build BRL-CAD without too much hassle, whereas Plan 9 doesn't even have CMake. (afaik)

starseeker (Apr 27 2018 at 10:38):

In principle Haiku should build BRL-CAD in non-graphical mode with gcc (they don't have Tk as far as I know so most of the GUI stuff wont' work), but there were issues the last time I tried it. It's true if you're looking for a Real Challenge Plan 9 will be the better bet, but if you're after a warm-up Haiku might be an easier first bite.

starseeker (Apr 27 2018 at 10:51):

@Peter Pronai Since your project focuses on search -exec and you're command line oriented, I should mention (if you haven't seen it already) that the CMake setting BRLCAD_ENABLE_TK can be set to off to turn off the GUI parts of the build

starseeker (Apr 27 2018 at 10:54):

starseeker (Apr 27 2018 at 10:56):

@Peter Pronai Typically I'm more active on IRC - I'll check in with Zulip daily, but if I (or someone) doesn't respond here right away the IRC channel is also worth a try.

Cezar (Apr 27 2018 at 11:00):

if i create a new file, in the copyright header, do i write the date as "2018-2018" or "1985-2018"?

starseeker (Apr 27 2018 at 11:00):

Cezar (Apr 27 2018 at 11:00):

starseeker (Apr 27 2018 at 11:00):

Cezar (Apr 27 2018 at 11:01):

i think there are some scripts to update the years, do they work if i just write 2018?

Cezar (Apr 27 2018 at 11:01):

starseeker (Apr 27 2018 at 11:01):

I believe so, but that's one to check with Sean (or make a small test file and try it out - put 2017 and see what it does...)

Cezar (Apr 27 2018 at 11:04):

Peter Pronai (Apr 27 2018 at 19:33):

@starseeker Thanks! ^u^
I also use IRC but I've seen more activity here. I'm raingloom on freenode.

Peter Pronai (May 05 2018 at 12:09):

sooo ugh, is doxygen set up to actually build some HTML docs? because I can't figure out where or if those docs are built,

Daniel Rossberg (May 05 2018 at 12:45):

There is a CMake parameter BRLCAD_EXTRADOCS_HTML which determines the build of HTML files. The corresponding docbook configurations can be found in doc/docbook/resources/brlcad (look for xhtml there).

starseeker (May 05 2018 at 18:11):

starseeker (May 05 2018 at 18:12):

Doxygen is separate from the DocBook system, actually - it reads specially formatted header comments to generate hyperlinked output

starseeker (May 05 2018 at 18:15):

starseeker (May 05 2018 at 18:16):

The actual targets (and overall structure of the Doxygen output) are managed by the files in misc/doxygen

Peter Pronai (May 05 2018 at 18:48):

Ooh, ok, I have to actually have doxygen installed. I guess that should have been obvious, but since almost all other dependencies are bundled, I didn't realize doxygen was missing.

Peter Pronai (May 05 2018 at 18:54):

XML Parsing Error: not well-formed Location: file:///home/rain/Sync/gsoc/build/debug/doc/doxygen_output/html/index.xhtml Line Number 28, Column 47:
</script><script type="text/javascript" async src="http://cdn.mathjax.org/mathjax/latest/MathJax.js"></script>
----------------------------------------------^

(in case the formatting gets messed up: the arrow points to just before the src attribute)

Peter Pronai (May 05 2018 at 18:55):

I think the standalone async word is not valid XML because attributes need to have values?? I haven't had to touch XML in a while (thankfully), so I'm not sure.

Peter Pronai (May 05 2018 at 19:10):

starseeker (May 05 2018 at 19:29):

yeah, Doxygen and Apache FOP (for DocBook PDF output) are too much trouble to bundle for the payoff involved

starseeker (May 05 2018 at 19:30):

Hmm... what version of doxygen? I don't know that that async would be coming from us...

Peter Pronai (May 05 2018 at 19:32):

1.8.14 (from Arch Linux repos, so it should be pretty vanilla and pretty up to date)

starseeker (May 05 2018 at 19:33):

Peter Pronai (May 05 2018 at 19:36):

starseeker (May 05 2018 at 19:40):

Peter Pronai (May 05 2018 at 20:35):

hmm, I'm trying to reproduce the error but I can't even find anything XHTML related for doxygen, I think BRL-CAD is doing some extra transformations??

Peter Pronai (May 05 2018 at 20:36):

like, I searhced "doxygen "xhtml"" on duckduckgo and it didn't give anything useful and there doesn't seem to be anything related to XHTML or HTML standards in the doxygen settings

Peter Pronai (May 05 2018 at 20:37):

starseeker (May 05 2018 at 22:19):

Peter Pronai (May 06 2018 at 08:54):

that didn't really make it verbose, so I'll try -DCMAKE_VERBOSE_MAKEFILE=ON instead

starseeker (May 06 2018 at 14:13):

@Peter Pronai That wouldn't make the doxygen output verbose directly, but you should see a line like:

cd home/user/brlcad/build/doc && /usr/bin/doxygen /home/user/brlcad/build/CMakeTmp/Doxyfile

starseeker (May 06 2018 at 14:14):

That tells you how to run doxygen directly - you can then run /usr/bin/doxygen by hand and tweak anything in the way of options or the Doxyfile inputs you need to

Sean (May 07 2018 at 17:40):

not really @Peter Pronai, we basically just run doxygen (which you should see with VERBOSE=1) so any errors would likely be related to our Doxyfile and options it specifies. looking at the error, it seems awfully related to the doxygen USE_MATHJAX option not working right.

Sean (May 07 2018 at 17:40):

starseeker (May 10 2018 at 11:19):

Peter Pronai (May 10 2018 at 11:59):

Peter Pronai (May 10 2018 at 17:17):

Peter Pronai (May 10 2018 at 18:01):

@Sean turning MathJax off solves the issue with the index page but I tried opening a page at random (Modules / Vector math) and I get another error:

XML Parsing Error: not well-formed Location: file:///home/rain/Sync/gsoc/build/debug/doc/doxygen_output/html/dd/d89/group__vmath.xhtml Line Number 8606, Column 558:
<p>a[W] = b[W]*c[W] - <a class="el" href="../../dd/d89/group__vmath.xhtml#ga87a89e52d2b9365de0ff9a37022fae54" title="Compute dot product of vectors at ‘a’ and ‘b’. ">VDOT(b, c)</a>; <a class="el" href="../../dd/d89/group__vmath.xhtml#ga1d68a1d8100285c871d639f4290c5a47" title="Store cross product of 3D vectors at ‘a’ and ‘b’ in vector at ‘o’. ">VCROSS(temp, b, c)</a>; <a class="el" href="../../dd/d89/group__vmath.xhtml#ga5331874932d6c7eec5e10f064837fff3" title="Compose 3D vector at ‘o’ of: Vector at ‘a’ plus scalar ‘sb’ times vector at ‘b’ plus scalar d84">Y</a></div><div class="ttdef"><b>Definition:</b> <a href="../../db/db3/vmath_8h_source.xhtml#l00398">vmath.h:398</a></div></div>
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^

Sean (May 16 2018 at 13:21):

XML Parsing Error: not well-formed Location: file:///home/rain/Sync/gsoc/build/debug/doc/doxygen_output/html/dd/d89/group__vmath.xhtml Line Number 8606, Column 558:
<p>a[W] = b[W]*c[W] - <a class="el" href="../../dd/d89/group__vmath.xhtml#ga87a89e52d2b9365de0ff9a37022fae54" title="Compute dot product of vectors at ‘a’ and ‘b’. ">VDOT(b, c)</a>; <a class="el" href="../../dd/d89/group__vmath.xhtml#ga1d68a1d8100285c871d639f4290c5a47" title="Store cross product of 3D vectors at ‘a’ and ‘b’ in vector at ‘o’. ">VCROSS(temp, b, c)</a>; <a class="el" href="../../dd/d89/group__vmath.xhtml#ga5331874932d6c7eec5e10f064837fff3" title="Compose 3D vector at ‘o’ of: Vector at ‘a’ plus scalar ‘sb’ times vector at ‘b’ plus scalar d84">Y</a></div><div class="ttdef"><b>Definition:</b> <a href="../../db/db3/vmath_8h_source.xhtml#l00398">vmath.h:398</a></div></div>
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------^

Cezar (May 19 2018 at 14:59):

compilation is broken under windows 10/vs 2017 with the latest sdk. i submitted a patch which changes CMakeLists.txt and contains some instructions. the error is actually caused by tk, and there are more details here

starseeker (May 19 2018 at 15:03):

@Cezar - how come you needed to change src/librt/primitives/bot/gct_decimation/auxiliary/mmthread.h

starseeker (May 19 2018 at 15:03):

Cezar (May 19 2018 at 15:04):

mm... i didn't really need to, and now that i think about it, it might have been wrong to do it :-?

Cezar (May 19 2018 at 15:05):

i removed the !defined(timespec), because i assumed it was checking for the existence of a struct timespec

starseeker (May 19 2018 at 15:06):

We just went round and round with that whole mmthread.h thing - it's possible there's still a problem, but I'd check the commit history on that first.

starseeker (May 19 2018 at 15:06):

Cezar (May 19 2018 at 15:07):

starseeker (May 19 2018 at 15:08):

Cezar (May 19 2018 at 15:08):

i don't think the part that #define'd timespec got moved :-? maybe that would've been the proper fix?

starseeker (May 19 2018 at 15:09):

Cezar (May 19 2018 at 15:10):

but currently, because HAVE_STRUCT_TIMESPEC is not defined for windows, and timespec is #define'd nowhere, struct timespec gets redefined inside that #if, and compilation fails

Cezar (May 19 2018 at 15:10):

i think people had the same problem previously, but it got fixed for linux alone

starseeker (May 19 2018 at 15:10):

OK, that might be - we do get away with it on VS2013, but newer ones may have an issue

starseeker (May 19 2018 at 15:10):

Cezar (May 19 2018 at 15:11):

starseeker (May 19 2018 at 15:11):

I bulled my way through that Tcl/Tk thing once when I had to in order to force a build, but a "proper" cleanup is some work

Cezar (May 19 2018 at 15:15):

i don't even know if it's possible. i don't think current the current tk version solved the problem

starseeker (May 19 2018 at 15:16):

starseeker (May 19 2018 at 15:17):

Yeah, unless something changed the last discussion I saw was along the lines of "fix it in 8.7, the older ones can use the older sdk"

starseeker (May 19 2018 at 15:18):

Cezar (May 19 2018 at 15:55):

Cezar (May 19 2018 at 15:56):

starseeker (May 19 2018 at 18:01):

Cezar (May 19 2018 at 18:03):

Cezar (May 19 2018 at 18:04):

starseeker (May 19 2018 at 18:16):

Out of curiosity, why did you want to not include stdio.h? (Usually, if we can rely on standard functionality cross platform, it's OK/preferred to do so.)

starseeker (May 19 2018 at 18:20):

For string to integer conversion, you can also take a look at bu_opt_int and bu_opt_long - they can be used to process individual strings as well. They're intended to encapsulate the standard ways to do that for option parsing purposes, but it works just as well for any string.

Cezar (May 19 2018 at 18:22):

i think the example test i was looking at parsed it by hand and i did something similar

Cezar (May 19 2018 at 18:22):

starseeker (May 19 2018 at 18:23):

pattern is if (bu_opt_int(NULL, 1, (const char *)&str, &var) > 0 { / use number */}

starseeker (May 19 2018 at 18:23):

Cezar (May 19 2018 at 18:23):

and i did not know about bu_opt_int/long, i can change the test and upload a new patch

starseeker (May 19 2018 at 18:25):

We should probably move the core logic of those to a top level API... they're not actually bu_opt specific really, but I'm not quite sure where they belong instead.

Cezar (May 19 2018 at 18:27):

hmm... the signature i'm finding is extern int bu_opt_long(struct bu_vls *msg, int argc, const char **argv, void *set_var)

starseeker (May 19 2018 at 18:27):

Cezar (May 19 2018 at 18:28):

starseeker (May 19 2018 at 18:29):

so if you have a string const char *nstr = "-1140404"; and a long int val;, you could do the following:

if (bu_opt_long(NULL, 1, (const char **)&nstr, (void )&val) > 0) { / do stuff */ }

starseeker (May 19 2018 at 18:29):

Cezar (May 19 2018 at 18:29):

Cezar (May 19 2018 at 18:30):

Cezar (May 19 2018 at 18:31):

oh, and the value is given as argument, not returned. don't know why i got confused, sorry :D

starseeker (May 20 2018 at 01:37):

@Cezar fundamentally, the string to number conversion process has to account for situations where the string does not in fact represent a number - that's why the return code contains that information, rather than returning the value.

starseeker (May 20 2018 at 01:38):

IIRC, in C++ the conversion functions use exception throwing, but in C we need other mechanisms

starseeker (May 20 2018 at 01:41):

@Cezar can you make one more patch that includes both the ptbl.c file and the CMake logic?

Cezar (May 20 2018 at 10:44):

starseeker (May 20 2018 at 14:13):

Jaipal Singh (May 25 2018 at 14:36):

Jaipal Singh (May 25 2018 at 14:37):

I've written the new doc in /doc/docbook/articles/en/myarticle.xml and have in the build directory, run >cmake ..

Jaipal Singh (May 25 2018 at 14:38):

But how do I get cmake to build specific target files? This makes the make file for the entire source code right?

Jaipal Singh (May 25 2018 at 14:40):

When I run cmake, one of the log lines reads : "Generate extra docs ...................: OFF
", I'm not sure if that's related to the problem though

starseeker (May 26 2018 at 02:03):

Sean (May 27 2018 at 18:59):

running "make VERBOSE=1" will show you exactly what commands are being run, that can often help diagnose

Jaipal Singh (Jun 06 2018 at 10:38):

When I'm changing some part of libged, do I need to rebuild everything or is there a way to just build the files I had just changed?

Saran Narayan (Jun 06 2018 at 11:08):

Saran Narayan (Jun 06 2018 at 11:09):

Jaipal Singh (Jun 06 2018 at 11:09):

Saran Narayan (Jun 06 2018 at 11:10):

Jaipal Singh (Jun 08 2018 at 07:30):

Daniel Rossberg (Jun 08 2018 at 07:41):

Jaipal Singh (Jun 08 2018 at 07:45):

Jaipal Singh (Jun 08 2018 at 08:01):

Tried routing via a VPN and these errors pop-up. https://pastebin.com/sxHmVdmY
Similar errors when routing SVN through the proxy server. Any clues on what I might be doing wrong?

Jaipal Singh (Jun 08 2018 at 09:33):

Update : This time the connection was established but it stopped downloading a little while into checkingout. When I tried again, it defaults back to the same error message. https://pastebin.com/aVL2vxz1

Jaipal Singh (Jun 08 2018 at 11:35):

Daniel Rossberg (Jun 08 2018 at 16:35):

Jaipal Singh (Jun 09 2018 at 06:05):

Jaipal Singh (Jun 09 2018 at 06:44):

@Daniel Rossberg Seems to be an issue with the timeout setting on the proxy server. I've managed to checkout the code though, through multiple iterations of svn cleanup + svn up.

Daniel Rossberg (Jun 09 2018 at 14:54):

Not necessarily, my guess is an authentication issue, your computer (or svn) fails to renew it.

Saran Narayan (Jun 09 2018 at 20:49):

src/libbu/malloc.c: In function ‘bu_realloc’:
src/libbu/malloc.c:232:11: error: variable ‘original_ptr’ set but not used [-Werror=unused-but-set-variable]
     void *original_ptr;

Sean (Jun 09 2018 at 21:12):

Sean (Jun 09 2018 at 21:17):

for what it's worth, build often breaks for one but not others due to our super aggressive warning settings. fixes for those sorts of failures are typically quite simple, so simple that generally whomever encounters the error just fixes it unless that code raises other questions. that said, it is the responsibility of whomever broke it to fix it relatively quickly (typically a day) or offending changes can be reverted (by anyone, providing details why)

Saran Narayan (Jun 09 2018 at 21:21):

Sean (Jun 09 2018 at 21:22):

Sean (Jun 09 2018 at 21:23):

Saran Narayan (Jun 09 2018 at 21:26):

Sean (Jun 09 2018 at 21:35):

Sean (Jun 09 2018 at 21:36):

you'll also want to run your code through "make test" from time to time (once a day or before anything major is typically enough)

Saran Narayan (Jun 09 2018 at 21:37):

Peter Pronai (Jun 10 2018 at 15:31):

@Jaipal Singh if you build the libged target it rebuilds the object files of the changed C files, and then links them all into libged
there is probably a way to build just the object file but I found that make libged finishes fast enough

Peter Pronai (Jun 10 2018 at 15:32):

at least AFAIK.
that's how makefiles work 99% of the time and based on the output I see that's what make libged does

Peter Pronai (Jun 10 2018 at 23:06):

so, I finally fixed doxygen, turns out it was just the file extension that needed to be changed

Cezar (Jun 25 2018 at 19:48):

i tried building inside a vm with debian 9 64-bit, gcc 6.3, 4 GB memory. it failed to build on release. here's the output

Cezar (Jun 25 2018 at 19:48):

Cezar (Jun 25 2018 at 19:49):

i tried disabling lto and i got similar errors, but no complaints about "plugin needed"

Sean (Jun 26 2018 at 22:33):

@Cezar try uncommenting the two inline-unit-growth lines in the top-level CMakeLists.txt file.. I don't recall there being a reason why they were commented out when lto was added, but they specifically fix the problem you ran into

Sean (Jun 26 2018 at 22:35):

@Cezar the plugin needed messages were very much because of lto and are a cmake mistake -- it needs to use gcc-ar and gcc-ranlib which are lto-aware, not the default system ar/ranlib. there is a simple check for "gcc-ar" in the top-level CMakeLists.txt file, so it'd be interesting to check your log and see why it failed to find it.

Cezar (Jun 27 2018 at 15:57):

i fixed the ar/ranlib error in r71094. it was a typo in CMakeLists.txt (CMAKE_X_COMPILER_VERSION instead of CMAKE_C_COMPILER_VERSION)

Cezar (Jun 27 2018 at 16:09):

as for the other error, i uncommented them, and only managed to get rid of those errors when setting inline-unit-growth=1000 (from 300) and large-function-growth=100000 (i had tried 10000 before and it hadn't worked)

Cezar (Jun 27 2018 at 16:10):

Cezar (Jun 27 2018 at 16:11):

Cezar (Jun 27 2018 at 16:12):

don't know if i should make inline warnings not an error (probably not), but i don't know what else to do

Sean (Jul 04 2018 at 04:34):

I saw that. awesome catch! wish cmake did better at reporting unknown variables. if you know of a general solution, would love to know about it...

Sean (Jul 04 2018 at 04:44):

@Cezar I suppose we should just turn off C++ inline warnings (again). those warnings in your logs are on default constructors. I'd say that's lame compiler behavior, almost certainly related to newer lto features.

C++ automatically inlines default constructors/destructors. an alternative fix would typically be to define an explicit destructor (in this case) in openNURBS, which will also probably make the warnings go away. I'd say go with the simplest route for now (disabling warnings at least for gcc) -- there's already a section in the top-level CMakeLists.txt file that does exactly this for gcc 4.8- (search for Wno-inline).

Cezar (Jul 04 2018 at 07:46):

there are some warnings that can be switched on when running cmake (for example, --warn-uninitialized, https://cmake.org/cmake/help/latest/manual/cmake.1.html). i tried running with that, but it doesn't catch the typo and it also throws a lot of other errors for uninitialized variables (they're justified, but running cmake still works)

Cezar (Jul 04 2018 at 07:48):

but the coala tool you mentioned previously seems to support linting CMake files, so maybe that would work

Sean (Jul 10 2018 at 22:16):

@Cezar comment in r71116 seems to be saying that finline-small-functions makes it work, yet you added fno-inline-small-functions. am I reading the wording wrong?

Sean (Jul 10 2018 at 22:18):

little concerned adding that flag to all builds as that's one of the main benefits of automatic inlining (auto-inlining small functions). i get that it causes an error, but that's potentially more aggressive than just having a switch that turns off/on flto.

Sean (Jul 10 2018 at 22:18):

warrants a speed test on a platform not showing the error if it's going to stay...

Cezar (Jul 10 2018 at 23:28):

@Sean the comment is wrong/a typo. i meant to say that adding fno-inline-small-functions fixes the error

Cezar (Jul 10 2018 at 23:29):

Cezar (Jul 10 2018 at 23:30):

Cezar (Jul 11 2018 at 18:15):

Cezar (Jul 11 2018 at 20:58):

~/brlcad-code$ cat ../brl-bench/summary-small-inline-*
Abs  ubuntu-vm 1247391.74   572840.79   602804.27   453492.32   590922.89707759.42  695868.57
*vgr ubuntu-vm 9104.38  8542.21 10750.92    8498.73 8359.35 47.75   7550.55
Abs  ubuntu-vm 1332976.93   575557.27   639075.99   524704.19   600983.27821103.65  749066.88
*vgr ubuntu-vm 9729.04  8582.72 11397.82    9833.28 8501.67 55.39   8016.65
~/brlcad-code$ cat ../brl-bench/summary-fno-small-inline-*
Abs  ubuntu-vm 1294609.82   587805.95   556949.27   461473.47   585801.37726860.66  702250.09
*vgr ubuntu-vm 9449.01  8765.37 9933.10 8648.30 8286.90 49.04   7521.95
Abs  ubuntu-vm 1264685.41   584929.95   619923.49   483975.67   532182.83664865.42  691760.46
*vgr ubuntu-vm 9230.60  8722.48 11056.24    9070.00 7528.40 44.85   7608.76

Cezar (Jul 11 2018 at 20:58):

Cezar (Jul 11 2018 at 20:59):

Sean (Jul 11 2018 at 21:00):

Sean (Jul 11 2018 at 21:02):

probably not because there's places where 6.3 is just fine with flto and the inlines

Sean (Jul 11 2018 at 21:02):

what we can do is disable flto by default and add it to HACKING steps to add the flag when making a binary release

Cezar (Jul 11 2018 at 21:03):

yeah, i thought about checking for debian somehow, but couldn't find something quick with cmake. i'm thinking of something like if 'debian in uname -a` :-?

Sean (Jul 11 2018 at 21:03):

or dig a little deeper and figure out what's specifically wrong, maybe file a gcc bug to see if one of their guys can help

Sean (Jul 11 2018 at 21:04):

Sean (Jul 11 2018 at 21:05):

the right thing would be to isolate the failure and create a cmake test for it, then respond when we are compiling in an environment that exhibits that problem (whatever the OS or compiler or libs or ...)

Cezar (Jul 11 2018 at 21:07):

i thought about looking at gcc, but it's kinda big so it would take some time :-?

Cezar (Jul 11 2018 at 21:07):

Sean (Jul 11 2018 at 21:07):

the one that was accommodating bad inline warnings, the Wno-inline C++ check that was gcc 4.3-

Cezar (Jul 11 2018 at 21:08):

what i've gathered so far is that the symbol not found is the virtual destructor for ON_3dPointArray, and that the problem was introduced when switching from C++11 to C++98

Sean (Jul 11 2018 at 21:09):

Sean (Jul 11 2018 at 21:10):

i.e., tools are telling you there is a problem, but it's still not clear from observation where the problem really is

Sean (Jul 11 2018 at 21:13):

could speculate all sort of possibilities, leading guesses being either a misconfigured tool chain or an error in the compiler's linker phase (perhaps even specific to how virutal destructors are handled in -std=c++98 mode)

Cezar (Jul 11 2018 at 21:16):

when the problem is exhibited, intersect.cpp.o does contain the symbol, but with local binding. when there's no problem, that symbol has weak (global) linkage. i don't think the linker is involved here, am i wrong?

Sean (Jul 11 2018 at 22:13):

Sean (Jul 11 2018 at 22:14):

symbols are not finalized -- in fact some versions of gcc stub special .o files that are only fully readable by flto-aware versions of ranlib/ar

Cezar (Jul 13 2018 at 04:02):

Cezar (Jul 15 2018 at 12:22):

i commented out the fno-small-inline-functions flag. i've been trying to isolate the problem and create a small program showcasing it, but i can't get to the bottom of it. i'll spend the rest of today on it, if i still can't recreate the problem, is it fine to leave it like this for the time being and come back to it at a later date? (since i haven't done much performance work lately)

Sean (Jul 16 2018 at 14:16):

yes it's fine to leave it -- I would say abandon it now instead of spending the rest of the day on it. so far most fingers are pointing to some pedantic or buggy interaction involving gcc+optimized+lto+stdc++ so all we need to do is eliminate/change one of them and move on.

Sean (Jul 16 2018 at 14:17):

turning off lto and adding no-small-inline-functions will both negatively affect performance, so it's not like turning one off vs the other is tremendously different

Sean (Jul 16 2018 at 14:19):

since we're not planning on staying on c++98 for much longer (maybe two more releases at MOST), it's probably worth just adding a note to try eliminating the no-small-inline-functions flag when the standard is upgraded to C++11

Peter Pronai (Jul 29 2018 at 15:44):

src/librt/primitives/script/script.c:231:47: error: ‘ptr’ undeclared (first use in this function)
     bu_vls_strcpy(&script_ip->s_type, (char *)ptr);
                                               ^~~

Peter Pronai (Jul 29 2018 at 23:53):

reminder that clang build is still broken. it's some nontrivial C++ thing so I have no idea how to fix it.

/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:55:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<directory *>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:99:24: note: while checking a default template argument used here
    AutoPtr<directory *> comb_dirs;
    ~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:49:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:55:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<directory *>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:273:24: note: while checking a default template argument used here
    AutoPtr<directory *> comb_dirs;
    ~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:49:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:55:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<rt_tree_array>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:321:26: note: while checking a default template argument used here
    AutoPtr<rt_tree_array> tree_list((struct rt_tree_array *)bu_calloc(node_count,
    ~~~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:49:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:55:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<rt_tree_array>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:476:26: note: while checking a default template argument used here
    AutoPtr<rt_tree_array> nodes(static_cast<struct rt_tree_array *>(bu_calloc(
    ~~~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/brlcad-code/src/librt/reduce_db.cpp:49:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
4 errors generated.

Shubham Rathore (Jul 30 2018 at 03:39):

src/librt/primitives/script/script.c:231:47: error: ‘ptr’ undeclared (first use in this function)
bu_vls_strcpy(&script_ip->s_type, (char *)ptr);
^~~

Ah.. didn't show on mine. (char*) ptr is commented. Just uncomment line 212 and 228 in script.c . I dont have code access right now, so couldn't do it myself. Cheers !

Peter Pronai (Jul 30 2018 at 22:06):

thanks, I figured it out afterwards but I wasn't sure if uncommenting those was the right thing to do, since I had no idea why they were commented

Cezar (Jul 30 2018 at 22:49):

../src/mged/cmd.c:196:44: error: no member named 'result' in 'struct Tcl_Interp'
    len = strlen(((Tcl_Interp *)userdata)->result);

Cezar (Jul 30 2018 at 22:54):

i think it's the fault of my tcl installation (macos default). i see there is a char *result member in tcl/generic/tcl.h

Sean (Jul 31 2018 at 03:29):

@Peter Pronai I just applied a change that should fix that failure. I don't have that recent a clang to test with, so please test it if you would.

Sean (Jul 31 2018 at 03:47):

../src/mged/cmd.c:196:44: error: no member named 'result' in 'struct Tcl_Interp'
len = strlen(((Tcl_Interp *)userdata)->result);

Sean (Jul 31 2018 at 03:51):

@Peter Pronai (fyi @starseeker) you'll need to change that to go through proper functions if you're going to be modifying the result string. You need to change mged_db_search_callback() to use Tcl_GetObjResult() and/or Tcl_GetStringResult() followed by Tcl_SetObjResult() to properly read/write the result string. There shouldn't be any direct access to ->result ...

Peter Pronai (Jul 31 2018 at 03:53):

Sean (Jul 31 2018 at 04:02):

Sean (Jul 31 2018 at 04:04):

ah, and looks like you need to avoid calling Tcl_GetStringResult ... that's obsolete, use the object method (there's a call to get a string representation, examples all throughout our code if you follow places where Tcl_GetObjResult is called

Peter Pronai (Jul 31 2018 at 23:35):

Sean (Aug 01 2018 at 04:44):

saying it's broken is not helpful without a log or more information on the error.

Sean (Aug 01 2018 at 04:45):

Peter Pronai (Aug 01 2018 at 14:11):

/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:62:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<directory *>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:1875:24: note: while checking a default template argument used here
    AutoPtr<directory *> region_dirs;
    ~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:56:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:62:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<char>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:2110:42: note: while checking a default template argument used here
    const std::string name = AutoPtr<char>(db_path_to_string(
                             ~~~~~~~~~~~~^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:56:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:62:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<char>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:2129:42: note: while checking a default template argument used here
    const std::string name = AutoPtr<char>(db_path_to_string(
                             ~~~~~~~~~~~~^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:56:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:62:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<directory *>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:2168:21: note: while checking a default template argument used here
        AutoPtr<directory *> region_dirs;
        ~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:56:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:62:43: error: non-type template argument referring to function 'autoptr_wrap_bu_free<directory *>' with internal linkage is a C++11 extension [-Werror,-Wc++11-extensions]
template <typename T, void free_fn(T *) = autoptr_wrap_bu_free>
                                          ^~~~~~~~~~~~~~~~~~~~
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:2213:24: note: while checking a default template argument used here
    AutoPtr<directory *> region_dirs;
    ~~~~~~~~~~~~~~~~~~~^
/home/rain/Sync/gsoc/build/svn-master/src/libgcv/plugins/fastgen4/fastgen4_write.cpp:56:1: note: non-type template argument refers to function here
autoptr_wrap_bu_free(T *ptr)
^
5 errors generated.

Peter Pronai (Aug 01 2018 at 14:12):

Peter Pronai (Aug 01 2018 at 14:13):

since the build stops after the first such error, there might be more lurking in other files

Sean (Aug 02 2018 at 06:27):

Sean (Aug 02 2018 at 06:32):

there is just at least one more, looks like someone made a copy of the same code, so fix should be the same or nearly the same. @Peter Pronai so see if you can fix this one (and any others like it) ...

Sean (Aug 02 2018 at 06:33):

that'd make a perfect succinct patch to submit, fixing the latest clang build issues

Sean (Aug 07 2018 at 05:35):

Peter Pronai (Aug 07 2018 at 19:02):

Peter Pronai (Aug 08 2018 at 19:17):

Peter Pronai (Aug 08 2018 at 19:18):

i already sent the patch yesterday but a build was still running and it was very late so i wasn't sure if it really fixed everything

Peter Pronai (Aug 09 2018 at 01:11):

uh. ran into another build error but it's too late so I'll explore it more tomorrow:

/home/rain/Sync/gsoc/brlcad-code/src/rt/viewxray.c:108:7: error: implicit declaration of function 'bu_file_mime' [-Werror,-Wimplicit-function-declaration]

the relevant header is included and it seems to contain the function definition so idk what's going on

Peter Pronai (Aug 09 2018 at 01:12):

compiler is clang, haven't tested it with gcc because cmake + recompilation take FOREVER

Peter Pronai (Aug 09 2018 at 01:24):

starseeker (Aug 09 2018 at 01:33):

@Peter Pronai you may need to clear the build directory, or at least the include directory in the build directory - Sean made some changes and mentioned there might be trouble with pre-existing build dirs

starseeker (Aug 09 2018 at 01:34):

Peter Pronai (Aug 09 2018 at 01:34):

starseeker (Aug 09 2018 at 01:35):

which version of clang are you using? just built with gcc, so nominally things should be working...

starseeker (Aug 09 2018 at 01:35):

Peter Pronai (Aug 09 2018 at 01:36):

it's probably not clang's fault, i just mentioned that for the record, in case it's another compiler weirdness

Peter Pronai (Aug 09 2018 at 01:36):

starseeker (Aug 09 2018 at 01:37):

heh - I might have to bootstrap that, I don't think my distros have such a new version. How is version 6 - any cool new features?

starseeker (Aug 09 2018 at 01:40):

@Peter Pronai got most of the patches applied, looking at #507 now. What's the "forgo burning memory" comment referring to?

Peter Pronai (Aug 09 2018 at 02:14):

oh, that's.... complicated. i was gonna do a string copy but then i realized i don't have to. i really should remove those comments >_>

starseeker (Aug 09 2018 at 02:14):

starseeker (Aug 09 2018 at 02:44):

@Peter Pronai I ended up reproducing your earlier build error - looks like removing the include directory in the build dir and re-running CMake fixed it for me.

Sean (Aug 09 2018 at 06:40):

Jaipal Singh (Aug 09 2018 at 11:13):

Shubham Rathore (Aug 09 2018 at 15:24):

Jaipal Singh (Aug 09 2018 at 15:24):

Jaipal Singh (Aug 09 2018 at 16:16):

Shubham Rathore (Aug 09 2018 at 17:03):

Jaipal Singh (Aug 09 2018 at 17:26):

Saran Narayan (Aug 09 2018 at 17:35):

Saran Narayan (Aug 09 2018 at 17:41):

Daniel Rossberg (Aug 09 2018 at 17:50):

In your build directory (!) remove the file include/bu/mime.h.
It was renamed to mime_types.h but the old mime.h still lies there. It conflicts now with the new include/bu/mime.h in the source directory.

Saran Narayan (Aug 09 2018 at 17:53):

Daniel Rossberg (Jan 15 2019 at 18:55):

Ngadou Yopa (Mar 23 2019 at 15:28):

Hey @all. Found a bug while building BRL-CAD. In the file brlcad-svn-trunk/src/libbu/tests/../../libbu/tests/mappedfile.c > main function, there is a variable "ret" of type int which is declared but not initialised

Ngadou Yopa (Mar 23 2019 at 15:29):

Daniel Rossberg (Mar 23 2019 at 16:00):

@Ngadou Yopa Which revision do you have? I don't see a compiler warning for the HEAD revision, and the initialization happens in line 196 and 199.

Ngadou Yopa (Mar 23 2019 at 16:02):

Daniel Rossberg (Mar 23 2019 at 16:02):

Ngadou Yopa (Mar 23 2019 at 16:03):

Ngadou Yopa (Mar 23 2019 at 16:04):

Daniel Rossberg (Mar 23 2019 at 16:06):

Ngadou Yopa (Mar 23 2019 at 16:08):

Daniel Rossberg (Mar 23 2019 at 16:11):

Ngadou Yopa (Mar 23 2019 at 16:13):

Ngadou Yopa (Mar 23 2019 at 16:14):

Ngadou Yopa (Mar 23 2019 at 16:16):

this was cause of some issues i faced. i found out in another documentation that the cmake was to be done in a build file
I wonder if that make much difference (i mean maybe i missed out a permission or something)

Ngadou Yopa (Mar 23 2019 at 16:17):

Daniel Rossberg (Mar 23 2019 at 16:17):

The name of the directory doesn't really matter. The main difference between .buid and build is that the first one is a hidden directory whereas the second is not.

Daniel Rossberg (Mar 23 2019 at 16:18):

For example, I prefer to have the build directory outside the checked out source code tree.

Daniel Rossberg (Mar 23 2019 at 16:19):

BTW, there is another mention of the .build directory on the wiki page in the Run! section.

Ngadou Yopa (Mar 23 2019 at 17:08):

Ngadou Yopa (Mar 23 2019 at 17:11):

I am stuck on this "build/mged" with the following error :

 if_X24: Unable to allocate 3221227008 bytes of backing store
  Run shell command 'limit datasize unlimited' and try again.
Segmentation fault

Ngadou Yopa (Mar 23 2019 at 17:12):

when i run
$ ulimit -a i get this :
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 22278
max locked memory (kbytes, -l) 16384
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 22278
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Daniel Rossberg (Mar 24 2019 at 12:11):

I can only guess: Do you run BRL-CAD in a virtual machine? Do you have a retina display? It wants to allocate 3 GByte of memory as backing store for the X-Window System. That's much.

Ngadou Yopa (Mar 26 2019 at 12:15):

Daniel Rossberg (Mar 26 2019 at 19:21):

@Ngadou Yopa Similar to what Sean said:
It's a good example to learn debugging. The error message comes from src/libfb/if_X24.c line 2061. Is the amount of memory reasonable?

Ngadou Yopa (Mar 26 2019 at 20:19):

Sorry for the late reply (my desktop client has issues connecting)
Of course :D debugging is a daily routine
I will check on that and report

Sean (Mar 26 2019 at 20:20):

Sean (Mar 26 2019 at 20:21):

perhaps something uninitialized, perhaps something corrupted, perhaps something computed incorrectly, perhaps something computed correctly from from bad values, etc..

Ngadou Yopa (Mar 26 2019 at 20:22):

Ngadou Yopa (Mar 27 2019 at 10:25):

It worked :D !
How ? I had to manually change the value of size variable. It is a temporal solution before i try to find the cause

Ngadou Yopa (Mar 28 2019 at 01:56):

Please now that i am almost done setting up, can i please know some tasks i might resolve so as to be able to draft an application ?

Mayank Madan (Mar 28 2019 at 07:25):

Same. I have setup the environment and have been playing around with the source for sometime now. It would be nice if there were some simple tasks to begin with

Sean (Mar 28 2019 at 18:17):

@Ngadou Yopa you could try ANY of the items listed in the TODO or BUGS files ... or run "make test" and investigate+fix any that fail. You'll need to be really good with a debugger to do the second one. Alternatively, you could implement something related to your proposal.

Sean (Mar 28 2019 at 18:18):

@Mayank Madan same advice as above. Depending on what project you are interested in, a good patch related to it helps demonstrate your ability level.

Ngadou Yopa (Mar 30 2019 at 12:59):

Great ! i will mostly concentrate on BRL-CAD itself. So i think "New BRL-CAD GUI" will be great

Sean (Mar 31 2019 at 17:46):

make sure to check out the previous GSoC GUI projects for context -- all previous GSoC projects are on our wiki. there's also GCI work that is very relevant which you can find with a google search.

Louis Googl (Mar 31 2019 at 23:07):

pasted image
hello , I have tried to build the source code using linux it all goes well but it is too slow on vm so I tried to do it on vs but I had a lot of non real errors as you can see in the image , help pleas what should I do ?

Sean (Apr 01 2019 at 03:38):

@Louis Googl looks like you don't have something configured right. Are your sources from a checkout or tarball? You should get a checkout and run cmake directly. That said, you should know that error counts are meaningless in Visual Studio beyond 0 and >0. You need to find the first error listed and look at that first. Everything else just cascades.

Louis Googl (Apr 01 2019 at 10:58):

actually I have the source code from svn check out the same check out that i used to build on Debian. I know that the error count doesn't mean any thing but i meant that the errors are not true because the brackets and semicolons that vs says are absent they aren't actually they are existed but there is spaces and new lines before them. thank you

Sean (Apr 01 2019 at 11:35):

@Louis Googl ah, that's just because it gets confused when a type has some unknown expression or is unknown itself. in this case, imagine if 'off_t' were #define off_t /nothing/ ... then you'd get something like the errors shown. That's not exactly what is going on here, but there is probably something wrong with a type somewhere. That's why you got to find the FIRST error listed.

Louis Googl (Apr 01 2019 at 11:44):

pasted image
pasted image
pasted image
this images of my configurations is there any thing wrong ? I looked at the first error it is not true just the rest of the function is in new line that is what causing the ")" error , and in the case of "off_t" the header file that contain it is existed when i press peek definition the error goes and get back in another files .

Sean (Apr 01 2019 at 13:52):

@Louis Googl you went too far back -- you want the first error from visual studio, not from cmake. cmake intentionally runs a lot of tests that will pass and fail as it probes your system for features. if cmake completes successfully (i.e., there's a summary table at the end and it generates successfully), then that step is fine. it's the first error in your studio log that matters.

Louis Googl (Apr 01 2019 at 23:44):

I fixed it the error was in Cmake because i was using win32 configurations and my system is X64 but during the building i got two errors and I rebuild it and they were gone but i couldn't run the debugger as you can see in the second image
pasted image
pasted image

Sean (Apr 01 2019 at 23:47):

either configuration should have worked, but glad you got a successful build. the first screenshot with the pix-bw error is a known issue, but not critical -- you can ignore. if you can figure it out what is causing that problem and a fix for it, that would make for an excellent gsoc application code patch to demonstrate ability.

Sean (Apr 01 2019 at 23:48):

ALL_BUILD is not a program -- it's a build rule that builds everything. that's why it gives you an error. You'd have to select a program solution to debug (e.g., "pix-bw" or "mged" or "rt").

Louis Googl (Apr 02 2019 at 19:28):

sorry i was not being attention to the starting point of debugging it works now thank you .
pasted image

Louis Googl (Apr 02 2019 at 19:39):

Sean (Apr 04 2019 at 00:13):

@Rajesh Kumar lets talk here instead of privately. others often face the same issues and can benefit. As to your build error, did you try following: http://brlcad.org/wiki/Compiling ?

Louis Googl (Apr 04 2019 at 16:58):

when debugging mged the debugger doesn't capture the events happening in the command window is it a separate application ? can you advice a way to capture the events in the command window ? thank you

Louis Googl (Apr 04 2019 at 17:00):

I have tried a lot with the assertion problem but i couldn't find the cause can you suggest another problem to make a patch for the application ?

Louis Googl (Apr 04 2019 at 17:15):

i can do it by placing braking points in functions I know it will call but is there another way ?

Rajesh Kumar (Apr 04 2019 at 20:04):

yes, I have already seen the article. It was quite informative. The SSL communication issue is due to some firewall or certificate issue. But It is quite persistent in its job. It can be resolved by repeatedly calling >> svn cleanup && svn up in source directory. but it would be great if any real solution comes up.
About the compiling, I finished making my svn checked out the brl-cad project with DCMAKE_BUILD_TYPE=Debug. I can't see if it created any .sln file or .xcodeproj. Am I missing something? .....It finished making successfully though but no debug pipeline.

Sean (Apr 05 2019 at 02:45):

the mged command window is not a separate application, but it is a Tcl shell -- so everything is being run within a Tcl event loop. you don't want to debug from there, though -- you'll usually want to debug from the commands that are run by the shell. Nearly all start with functions of a similar name, like ged_tops() when you run the 'tops' command or ged_list() for the 'ls' command. There's a table of them you can find in src/mged.

Sean (Apr 05 2019 at 02:48):

Fixing any bug you find is always an excellent candidate. Anything in the BUGS and TODO files too.

Sean (Apr 05 2019 at 02:51):

That is the best way. You can run mged with options (e.g., mged -c) to run without a GUI or in command mode (e.g., mged file.g tops) where it's not quite so bad even to step through all of the Tcl processing, but setting a breakpoint on a function or file:line that you are interested in works really well for most debugging needs.

Louis Googl (Apr 08 2019 at 01:35):

hello , I have manged to fix the assertion error it was in the file pix-bw.c the reason is there is a condition is not true because of a short-circuit evaluation you can see in the first image is the original code and in the second there is my suggestion to fix the fix is correct because the assertion error is gone but I am 90% sure that my if statements keep the execution correct
pasted image
pasted image
is this enough to make a patch for the application ? because there are little time left

Sean (Apr 08 2019 at 02:31):

@Louis Googl will definitely look at your changes in a bit, but just be sure to mention it in your proposal somewhere. Anything you work on code-wise is "enough" ... it's just a matter of how much you want to impress or improve your chances of selection. Some continue to work on patches post submission deadline, which is also fine. Just be sure you don't submit your FINAL proposal PDF too late. It must be before the deadline.

Louis Googl (Apr 08 2019 at 02:36):

@Sean thank you , do I have to make a pull request? or just mention the fix in the proposal ?

Sean (Apr 08 2019 at 02:52):

You should definitely submit it. That will likely be a patch file submission on our Sourceforge project page. There's a wiki page that explains what you need to do (brlcad.org/wiki/Patches).

Sean (Apr 08 2019 at 02:53):

and so you'll submit a patch for our SVN repo or pull request if it's a GIT repo, and then mention it in your proposal.

Louis Googl (Apr 08 2019 at 03:32):

Louis Googl (Apr 08 2019 at 22:27):

@Sean I have shared the proposal and submitted the PDF in case you didn't fined time to give me feed back , I hope that you can :grinning: .thank you

Louis Googl (Apr 10 2019 at 08:18):

can I keep working on the patch even if I put a link to it in the proposal ?

Sean (Apr 10 2019 at 15:39):

absolutely can keep working on patches. in fact, it's highly recommended as it shows interest and initiative.

Louis Googl (Apr 12 2019 at 17:35):

I am trying to reproduce the annotations bugs in the bug file but there is no leader line in the results . are all the changes made in the 2017 project is applied to the svn version or I have to apply the patches by myself?
pasted image
pasted image

Sean (Apr 12 2019 at 18:15):

@Louis Googl They "should" all be applied, but if there are patches still open, some may have been missed. Basically, "don't know, you'll have to check"... which would be very helpful regardless. ;)

Louis Googl (Apr 12 2019 at 18:26):

Sean (Apr 12 2019 at 19:07):

Sean (Apr 12 2019 at 19:09):

I don't know what you've done, so don't know what to expect. The bug report says what the observed bugs were when they were written, but that doesn't mean there aren't more issues. whether there are leader lines, whether there are supposed to be leader lines, whether the point value is drawn or the label or both .. i believe they are all 'in' command parameters. If you run the 'in' command without any arguments, you'll see what each of the values is supposed to mean.

Daniel Rossberg (Apr 13 2019 at 16:10):

Daniel Rossberg (Apr 13 2019 at 16:12):

@Louis Googl It looks like you are using Windows? Do you have an idea why the line isn't visible? Can you debug this issue?

Sean (Apr 13 2019 at 16:12):

Sadeep Darshana (Apr 13 2019 at 19:32):

does mged directory contain archer's codes also? when old_mged_gui = 1 , archer launched instead of mged

Sean (Apr 13 2019 at 19:33):

Sean (Apr 13 2019 at 19:52):

actually they do share a fair bit of other library code in addition to libged such as libfb, libdm, libbu, libbn, etc but their front-end code is not shared. archer (in src/archer) is nearly pure Tcl GUI that calls code in src/tclscripts/archer whereas mged (in src/mged) has C code for command-line mode as the Tcl GUI code is in src/tclscripts/mged

Louis Googl (Apr 13 2019 at 21:48):

@Daniel Rossberg yes i am using windows , at first i thought that the line is not visible because the patches is not applied on the svn version , of course I will try to debug it . but do you think the bug is in the annotation primitive or in the Tcl commands ?

Sadeep Darshana (Apr 14 2019 at 16:37):

Daniel Rossberg (Apr 14 2019 at 17:52):

@Louis Googl My guess would be that the difference comes from differences in the display manager implementation. Which one is used in your case? Which function draws the annotation text? Is it ogl_drawVList()?

Sean (Apr 14 2019 at 17:54):

@Sadeep Darshana there is no difference between those two commands. If you run "svn help checkout", you'll see that brlcad-code vs brlcad is just the name of the directory to use for the checkout (otherwise it would use 'trunk').

Louis Googl (Apr 16 2019 at 00:14):

I was working for two days to find an answer that doesn't makes me look stupid :grinning: . actually I tried to construct the annotation while debugging the application and I put a breaking point in the typein.c and followed the execution step by step entering the parameters after that the program goes to the process of drawing new made solid like in this image
pasted image
you asked me about ogl_drawVlist this function is existed in the source code but after configuration with cmake the file contains it doesn't exist any more in the solution I Opened the file dm-ogl.c from outside and put the brake point in ogl_drawVlist() it doesn't call it at all pasted image

Louis Googl (Apr 16 2019 at 00:22):

Daniel Rossberg (Apr 16 2019 at 06:54):

svn checkout https://svn.code.sf.net/p/brlcad/code/brlcad/trunk brlcad is the command line at a shell, but you are using a GUI. Therefore, after selecting "SVN Checkout..." the "URL of repository:" is https://svn.code.sf.net/p/brlcad/code/brlcad/trunk and brlcad corresponds to "Checkout directory:".

Daniel Rossberg (Apr 16 2019 at 08:02):

Daniel Rossberg (Apr 16 2019 at 17:39):

I could reproduce the issue with Visual Studio on Windows, and I think I know why. The different behavior seems to be caused not by the different OS but the different compilers or compiler settings. However, wgl_drawVlist() is a good entry point to debug this.

Louis Googl (Apr 18 2019 at 22:35):

@Daniel Rossberg I found the cause of the error and I fixed it , it works but I don't think this is the best solution
pasted image
the reference point of this annotation is (30,30) the error in wgl_drawVlist is in pt the third coordinate of the point or we can say the third index of the vector is not initialized
pasted image
this happens for the annotated point in this case (0,0) and the reference point (30,30) this goes back to annot.c
pasted image
the pt variable is an array of 4 double numbers when we store the reference point and the annotated point in it using V2ADD2 macro pasted image
the first two indexes will be correct but the other two will not have any meaning so when it goes inside (vhead) to wgl_drawvVlist we will have a victor with three indexes but the third one has no meaning so my fix is to initialize pt in annot.c by zeroes this will make every thing go well but I don't think this is the best solution because if when we want to make the reference point in 3d the third index will not always be zero . pasted image

Louis Googl (Apr 18 2019 at 22:42):

I think now I have a clear Idea how to implement my proposal because I have understand how ant_to_vlist() and seg_to_vlist works .

Louis Googl (Apr 18 2019 at 23:01):

@Sean I tried to rethink the situation by implementing some thing like the condition here pasted image
by comparing some pointers with Null as it defined (void *)0 pasted image
the result of execution of this program shows that the (is equal) operator is evaluated before the ( logical and )
pasted image
so the condition here is not doing what we want it to do if we try to put brackets to force the evaluation of logical and first the (is equal ) will be between a number and a pointer which will keep the assertion error so I think me batch do the job. I hope you give me some feed back and correct me if i did some thing wrong. thank you

Sean (Apr 19 2019 at 07:09):

Please don't struggle for days. Some code is considerably more complicated to diagnose and debug than others, and the plot code tends to be fall in that category when things go wrong. It's conceptually not complicated, but it can be very hard to debug as differences can come from different compilation settings, different versions of Tcl, different behavior in mged classic vs mged GUI vs archer, different display manager, different platform/opengl/driver behavior, etc.

So that's the hardcore hard way and a reasonable way to get started, but you got the wrong file -- the ogl interface is what's used on Linux and BSD. You want to look at the dm-wgl.c file and the vlist handling there.

Sean (Apr 19 2019 at 07:24):

And I see your follow-up analysis is spot on. That's outstanding and I think you pinned the bug perfectly. The issue is API mismatch. Instead of an array of double[2] or double[4] even on line 333, it should be using vmath.h types (e.g., point_t) and using initializer macros if it's going to be using vmath macros. It looks like the code is treating a double array as a vect2d_t and passing that to the vlist code, which is assuming a point_t. It should work if you use point_t pt = VINIT_ZERO; ... can you test that? If so, that'll be a simple patch.

So the technical reason it sometimes did and did not draw is likely because memory is typically initialized to zero for debug builds and random garbage for optimized builds -- and in this context, random garbage is even out of bounds and regardless will likely be a large value which will get zclipped (not drawn).

Sean (Apr 19 2019 at 07:25):

if it really does need the 4th parameter, it would be good to know why (and that would be an hvect_t).

Sean (Apr 19 2019 at 07:51):

@Ngadou Yopa did you ever figure out what was going on here and submit a patch for it? Did you submit any patches?

Daniel Rossberg (Apr 19 2019 at 13:04):

@Louis Googl You pinned the reason for this bug, but why has the original programmer chosen a different type for pt than for for example center or start_pt? Well, the straight answer is: Because the code was taken from src/librt/primitives/sketch/sketch.c. I.e., the sketch should have similar issues than the annotation.

But then? pt is used in the CURVE_NURB_MAGIC section as well, and nmg_nurb_c_eval() seems to like an array of 4 doubles as third parameter. This is where the 4 came from. I.e., your solution is probable the best what one can do here. Another possibility, which means the same is hpoint_t pt = HINIT_ZERO;.

BTW, not all calls of nmg_nurb_c_eval() are using hpoint_t. Some use point_t. I hope everybody knew what they did there.

Louis Googl (Apr 19 2019 at 18:08):

@Sean thank you for the feed back I will try to do the patch today, but if I didn't have time i will do it next week because I am going to Rome in the holiday :grinning: happy Easter for every body .

Louis Googl (Apr 19 2019 at 18:09):

@Daniel Rossberg thank you for the feed back I will try to under stand why he put the variable in this way and make a nicer fix using macro initialization.

Louis Googl (Apr 19 2019 at 18:59):

@Daniel Rossberg @Sean I found the error causing the first bug in the bug file where the annotation appear to be pointing to (0 , 0 , 0) and I made a fix it works but I have another tow Ideas for the fix pasted image
the cause of the error is in seg_to_vlist()
pasted image
when trying to send the annotated point to the list pasted image
we can see that annot_ip->verts[lsg->end] is not a point or is not initialized correctly and it didn't contain the coordinates of the annotated point so me fix is to save the coordinates of the annotated points in a point and pass it to the list
pasted image
pasted image
so the error may be in annot-ip->verts . the second Idea is fix verts to be verts[1] contains the annotated point.
the third Idea is when you go to wgl_drawVlist() the annotated point is the first point in the list but with a cmd=15 which I don't know what it means but even if we fix it from here the third point in the list pt[2] will always be (0,0,0) because of the annot_ip->verts[1] error . I hope you give me feed back thank you very much .

Louis Googl (Apr 19 2019 at 19:07):

Louis Googl (Apr 19 2019 at 19:08):

Louis Googl (Apr 19 2019 at 19:11):

when pt goes inside V2ADD2 the result of pt will always be (0 , 0 , 0 )
pasted image

Louis Googl (Apr 19 2019 at 19:12):

Louis Googl (Apr 19 2019 at 19:13):

Louis Googl (Apr 19 2019 at 19:14):

i am sorry for uploading the images twice but they didn't appear in the first time .

Louis Googl (Apr 19 2019 at 19:21):

Louis Googl (Apr 20 2019 at 10:47):

Daniel Rossberg (Apr 20 2019 at 12:13):

@Louis Googl What was wrong with your first fix for the annotation bug you found? You nailed the cause as an initialization issue: The z coordinate of the pt vector wasn't initialized explicitly, so the compiler decided about it. The GNU compiler seems to initialize the variables with 0 by default. Visual Studio uses a different bit-pattern which looks bad as double (but is in fact good because it makes such initialization issues obvious). Therefore, the solution is to explicitly initialize pt as you did.

Then there is of cause the question why the pt vector looks so different than the other vectors there. The answer is, because it is used with a function which expects a homogeneous coordinate.

Louis Googl (Apr 20 2019 at 12:25):

the new post is for the annotation appear to point to the origin pasted image
for the leader line is not drawn bug there is no thing wrong with the fix because the initialization solves the problem but my Idea is when we are going to use 3d point in annotations the value of the third coordinate of pt has to be determined using a macro other than V2ADD2 . when you can pleas give me feed back for the bug that makes the annotation always point to origin.

Louis Googl (Apr 20 2019 at 13:34):

I have submitted the batch of the leader line @Sean @Daniel Rossberg , thank you for help.

Ngadou Yopa (Apr 20 2019 at 14:34):

Sean (Apr 20 2019 at 15:07):

Louis Googl (Apr 20 2019 at 16:06):

:grinning:thank you, at first i didn't know what 15 means but i knew it hase some thing to do with vdraw because cmd turns to 1 when the line has to be drawn and 0 when it wants to move to a certain point.

Daniel Rossberg (Nov 17 2019 at 20:16):

/home/rossberg/Devel/BRL-CAD/build/brlcad/src/other/stepcode/src/express/ExpParser_expparse/expparse.y: In function ‘yyStackOverflow’:
/home/rossberg/Devel/BRL-CAD/build/brlcad/src/other/stepcode/src/express/ExpParser_expparse/expparse.y:2479:50: error: ‘yypMinor’ undeclared (first use in this function); did you mean ‘yyerror’?
     fprintf(stderr, "Last token had value %x\n", yypMinor->yy0.val);
                                                  ^~~~~~~~
                                                  yyerror

I started from an empty build directory on Linux (latest Debian buster).
It looks like the parser generated a function static void yyStackOverflow(yyParser *yypParser) but it should be static void yyStackOverflow(yyParser *yypParser, YYMINORTYPE *yypMinor).
No idea what happened here. I could not find a relevant change to stepcode or lemon in the last time. :thinking:

Daniel Rossberg (Nov 17 2019 at 20:28):

Daniel Rossberg (Nov 17 2019 at 20:47):

Daniel Rossberg (Nov 18 2019 at 03:35):

Note: On latest Debian buster, the bundled libpng doesn't go together with Qt. If a BRL-CAD Qt application shall be build, the system provided libpng has to be used.

Sean (Nov 18 2019 at 16:46):

Daniel Rossberg (Nov 18 2019 at 17:45):

Daniel Rossberg (Nov 22 2019 at 21:31):

Unfortunately, this isn't the only difference. The type of the third parameter of "syntax_error" has changed too. I.e., the error reporting works whether with the old or new lemon, but not with both (wfobj).

Erik (Nov 24 2019 at 14:47):

Sean (Nov 24 2019 at 15:15):

I've built against 4 before, I'm pretty sure it worked ... but it goes hand-in-hand with Tcl/Tk with the latest.
The Tcl/Tk update is going to take a little bit of work because they modified bits of incr behavior that we're using.
Nothing hard, but it's probably a week of work to fix.

Erik (Nov 24 2019 at 15:28):

Sean (Nov 24 2019 at 16:04):

Sean (Nov 24 2019 at 16:05):

I've found that if I can't think through how many lines of code are involved, that tends to be a good measure of a task they never complete adequately (if they even try). much better are tasks telling them to do something very specific.

Daniel Rossberg (Mar 19 2020 at 16:50):

Sean (Mar 19 2020 at 16:52):

There is one that runs every mged command, but not one for every program -- mostly the integration and regression tests in regress which exercise about 30 of the more essential ones, some which run on Windows and a lot that do not unless you're in gitbash.

Sean (Mar 19 2020 at 16:53):

Like the idea, though, could easily do something similar to the mged command tester.

Daniel Rossberg (Mar 19 2020 at 16:54):

I just wanted to test fstat(), but found that only few programs use it.
However, the test was successful for the standard build. I used glint.

Daniel Rossberg (Mar 19 2020 at 16:57):

Therefore, it would be good to have a test which runs every program once.
My standard "test" is running mged, but there is stuff (like rt_dirbuild()) which is not covered by this.

Sean (Mar 19 2020 at 16:57):

I believe any .g application will end up calling fstat because the mappedfile interface in libbu uses it, and g files are opened through the mapped file interface

Daniel Rossberg (Mar 19 2020 at 17:00):

Unfortunately, this is not the case. db_open() (used for writable files) doesn't use the mapped files.

Daniel Rossberg (Mar 19 2020 at 17:05):

Sean (Mar 19 2020 at 17:10):

Ah, you're right, only read-only access goes through mapped file but that's still a significant number of access points which are part of the regression testing.

Sean (Mar 19 2020 at 17:12):

all the primitives that have an outboard file, texture mapping, dsp terrain data, rtweight density file, ebm, nurbs prep caching, ...

Sean (Mar 20 2020 at 20:35):

<http://brlcad.org:8888/status/job/BRL-CAD/default/ws/brlcad.trunk/src/libanalyze/nirt/diff.cpp>:303:69: error: struct 'half_segment' was previously declared as a class; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Werror,-Wmismatched-tags]
   std::map<long, std::map<long, std::map<n_transition_t, std::set<struct half_segment>>>> ordered_transitions;
                                                                   ^
<http://brlcad.org:8888/status/job/BRL-CAD/default/ws/brlcad.trunk/src/libanalyze/nirt/diff.cpp>:118:7: note: previous use is here
class half_segment {
     ^
<http://brlcad.org:8888/status/job/BRL-CAD/default/ws/brlcad.trunk/src/libanalyze/nirt/diff.cpp>:303:69: note: did you mean class here?
   std::map<long, std::map<long, std::map<n_transition_t, std::set<struct half_segment>>>> ordered_transitions;
                                                                   ^~~~~~
                                                                   class
<http://brlcad.org:8888/status/job/BRL-CAD/default/ws/brlcad.trunk/src/libanalyze/nirt/diff.cpp>:312:6: error: struct 'half_segment' was previously declared as a class; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Werror,-Wmismatched-tags]
           struct half_segment in_seg;
           ^
<http://brlcad.org:8888/status/job/BRL-CAD/default/ws/brlcad.trunk/src/libanalyze/nirt/diff.cpp>:118:7: note: previous use is here
class half_segment {
     ^
<http://brlcad.org:8888/status/job/BRL-CAD/default/ws/brlcad.trunk/src/libanalyze/nirt/diff.cpp>:312:6: note: did you mean class here?
           struct half_segment in_seg;
           ^~~~~~
           class
... lots more

starseeker (Mar 20 2020 at 20:42):

starseeker (Mar 28 2020 at 03:03):

@starseeker is going to start dreaming in CMake before too much longer... blegh.

Daniel Rossberg (Mar 28 2020 at 15:33):

BTW, my tests with VS2019 builds were all successful, including the ones with the brlcad.dll.

starseeker (Mar 28 2020 at 16:26):

starseeker (Mar 31 2020 at 19:40):

@Daniel Rossberg you may want to hold off updating for the next few days - I'm looking at migrating Tcl/Tk versions, and there's almost certain to be some build system thrashing in the process.

Daniel Rossberg (May 15 2024 at 16:49):

Some observations regarding the new build of external dependencies, i.e. during the CMake configuration:

Cloning the gdal repository failed because of too long paths. For a quick solution, I disabled GDAL.

Building TCL failed because Visual Studio could not be found, even if vcvars.bat(?) was called. The solution was to leave the GUI, open the Visual Studio command prompt, navigate to the build directory, and call camke . there. After this succeeded, I could proceed with the CMake GUI.

After the Visual Studio solution and project files were written, the compilation was successful too, except for two test programs, where the main function could not be found.

I'm still trying to build the brlcad.dll, at least somehow. Currently I'm struggling with unresolved static openNurbs classes (like static const ON_Interval::ZeroToTwoPi).

Daniel Rossberg (May 15 2024 at 17:26):

invalid command name "gui"
MGED unable to initialize gui, reverting to classic mode.
attach (nu ogl X ps txt)[nu]?

starseeker (May 15 2024 at 17:55):

The latter I've seen occasionally when the Tcl environment doesn't get set up correctly, but I'm not 100% what's causing it - are the tclIndex and pkgIndex files present in your build?

starseeker (May 15 2024 at 17:55):

starseeker (May 15 2024 at 18:00):

I've seen that gdal issue on the runners - it seems to be related to test files we don't need, so I've removed them and updated bext accordingly.

starseeker (May 15 2024 at 18:03):

@Daniel Rossberg For avoiding the Tcl issues on Windows (at least, with the main BRL-CAD build) I'd suggest building the bext repository separately, and then using the BRLCAD_EXT_DIR to point to the bext_output directory. That way you can do the bext build on the command prompt (which I agree seems to be the only reliable way at the moment to get the Visual Studio environment setup that Tcl's build is looking for) but still do the BRL-CAD build via the Visual Studio GUI.

starseeker (May 15 2024 at 18:05):

starseeker (May 15 2024 at 18:08):

That's actually the recommended way - you can fully rebuild BRL-CAD using this approach without having to pay the price to recompile bext as well, so it can be pretty handy.

starseeker (May 15 2024 at 18:47):

@Daniel Rossberg I think if you call cmake on the Developer command prompts you're getting the built-in CMake with Studio, rather than the one from the GUI. That will usually work, I think, but my suggestion would be not mix the two...

When I've built lately, I launch the Developer Powershell prompt from Windows, make a build directory, and then run cmake on the command prompt (both for configure and building) - like in the bext readme: https://github.com/BRL-CAD/bext

starseeker (May 15 2024 at 19:15):

starseeker (May 15 2024 at 21:55):

@Daniel Rossberg I just pushed a change that should help with the "MGED unable to initialize" problem.

starseeker (May 15 2024 at 21:59):

If you want to "fix" an existing build, try removing the src/tclscripts/tclindexbld.sentinel file and re-running the build step. It looks like what happened was it was running that target before everything was properly in place due to the dependencies not being set up right, and it thought it was "done" - even though it ran the scan before the files where actually there and ended up thinking it had no packages.

starseeker (May 15 2024 at 21:59):

So if the setup targets happened to run first, it would work, but if not then you would get what you saw - an MGED that knows nothing about any of its packages. Fun.

starseeker (May 15 2024 at 22:01):

Not sure what would be going on with the OpenNURBS classes - we did upgrade OpenNURBS when we shifted to the new dependency setup, so that's one possibility.

Daniel Rossberg (May 16 2024 at 07:26):

Daniel Rossberg (May 16 2024 at 07:27):

Daniel Rossberg (May 16 2024 at 07:28):

Daniel Rossberg (May 16 2024 at 09:31):

:+1:
It looks like this did it :smile:
(tested on another machine but with same OS, from scratch, etc.)

Daniel Rossberg (May 16 2024 at 16:45):

Sean (Jul 03 2024 at 06:12):

[ 43%] Built target gcv-decimate
[ 43%] Built target gcv-fastgen4
[ 44%] Linking CXX shared library ../../../../libexec/gcv/libgcv-gdal.dylib
ld: warning: ignoring file /Library/Frameworks/gdal.framework/gdal, file is universal (i386,x86_64) but does not contain the arm64 architecture: /Library/Frameworks/gdal.framework/gdal
Undefined symbols for architecture arm64:
  "_CPLPopErrorHandler", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_CPLPushErrorHandler", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_CPLQuietErrorHandler", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_GDALAllRegister", referenced from:
      gdal_can_read(char const*) in gdal.cpp.o
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALAutoCreateWarpedVRT", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALClose", referenced from:
      gdal_can_read(char const*) in gdal.cpp.o
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALComputeRasterMinMax", referenced from:
      gdal_elev_minmax(void*) in gdal.cpp.o
  "_GDALGetGeoTransform", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_GDALGetProjectionRef", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_GDALGetRasterBand", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
      gdal_elev_minmax(void*) in gdal.cpp.o
  "_GDALGetRasterBandXSize", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALGetRasterBandYSize", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALGetRasterMaximum", referenced from:
      gdal_elev_minmax(void*) in gdal.cpp.o
  "_GDALGetRasterMinimum", referenced from:
      gdal_elev_minmax(void*) in gdal.cpp.o
  "_GDALGetRasterUnitType", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALGetRasterXSize", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_GDALGetRasterYSize", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_GDALInfo", referenced from:
      get_dataset_info(void*) in gdal.cpp.o
  "_GDALOpenEx", referenced from:
      gdal_can_read(char const*) in gdal.cpp.o
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALRasterIO", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALTranslate", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALTranslateOptionsFree", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_GDALTranslateOptionsNew", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "_OCTNewCoordinateTransformation", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_OCTTransform", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_OSRCloneGeogCS", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_OSRDestroySpatialReference", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_OSRNewSpatialReference", referenced from:
      gdal_ll(void*, double*, double*) in gdal_ll.cpp.o
  "_VSIFree", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
      get_dataset_info(void*) in gdal.cpp.o
  "GDALDataset::GetRasterBand(int)", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "OGRSpatialReference::importFromProj4(char const*)", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "OGRSpatialReference::OGRSpatialReference(char const*)", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "OGRSpatialReference::~OGRSpatialReference()", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "OGRSpatialReference::exportToWkt(char**) const", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
  "OGRSpatialReference::exportToProj4(char**) const", referenced from:
      gdal_read(gcv_context*, gcv_opts const*, void const*, char const*) in gdal.cpp.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libexec/gcv/libgcv-gdal.dylib] Error 1
make[1]: *** [src/libgcv/plugins/gdal/CMakeFiles/gcv-gdal.dir/all] Error 2
make: *** [all] Error 2

Sean (Jul 03 2024 at 06:13):

Sean (Jul 03 2024 at 06:14):

Sean (Jul 03 2024 at 06:16):

compile line seems to have replaced the prebuilt with the framework, so is apparently related:

cd /Users/morrison/brlcad.main4/.build/src/libgcv/plugins/gdal && /opt/homebrew/Cellar/cmake/3.28.3/bin/cmake -E cmake_link_script CMakeFiles/gcv-gdal.dir/link.txt --verbose=1

/Library/Developer/CommandLineTools/usr/bin/c++ -std=c++17 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -pipe -fvisibility=hidden -fno-strict-aliasing -fno-common -fexceptions -ftemplate-depth-128 -m64 -g -ggdb3 -Qunused-arguments -fstack-protector-all -pedantic -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation -Werror -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -dynamiclib -Wl,-headerpad_max_install_names -m64 -g -ggdb3 -o ../../../../libexec/gcv/libgcv-gdal.dylib -install_name @rpath/libgcv-gdal.dylib "CMakeFiles/gcv-gdal.dir/gdal.cpp.o" "CMakeFiles/gcv-gdal.dir/gdal_ll.cpp.o" -F/Library/Frameworks -Wl,-rpath,/Users/morrison/brlcad.main4/.build/lib ../../../../lib/libwdb.20.0.1.dylib ../../../../lib/librt.20.0.1.dylib -framework gdal ../../../../lib/libbrep.20.0.1.dylib ../../../../lib/libnmg.dylib ../../../../lib/libbv.20.0.1.dylib ../../../../lib/libbg.20.0.1.dylib ../../../../lib/libbn.20.0.1.dylib ../../../../lib/libbu.20.0.1.dylib -ldl ../../../../lib/liblmdb.dylib -framework System -lm ../../../../lib/libopenNURBS.dylib ../../../../lib/libmanifold.dylib ../../../../lib/libassimp.dylib ../../../../lib/libgeogram.dylib ../../../../lib/libregex_brl.dylib

Sean (Jul 03 2024 at 06:35):

so if I'm following the logic, that means BRLCAD_Find_Package(GDAL REQUIRED) in src/libgcv/plugins/gdal/CMakeLists.txt is preferring the framework to the one we built despite being bundled+enabled due to it calling FindPackage(GDAL)

Sean (Jul 03 2024 at 06:57):

Not clear how it worked before as I had a bext bundled build a while back, but forcing frameworks last does get past that issue and build succeeds.

Sean (Jul 11 2024 at 05:51):

@starseeker just FYI, lots of compilation errors in 'lief' on a SUSE Linux compile farm server with a default gcc7.5.0 (2019). Appears to be a handful of c++17 issues. Got up to about a dozen files and 2 hours into edits to get past errors before I bailed and installed gcc into my userspace. Is that dependency new? Critical? I don't recall encountering it before.

starseeker (Jul 11 2024 at 11:45):

@Sean LIEF is what allows us to rewrite the rpath in binaries. It's the non-GPL alternative to patchelf.

starseeker (Jul 11 2024 at 11:46):

gcc 7 I would not expect to work with quite a number of our dependencies, to be honest - that's pretty old.

Sean (Jul 11 2024 at 17:21):

I know what it is -- was more a question if it was introduced relatively recently, and how critically...

starseeker (Jul 11 2024 at 17:23):

It was introduced in late 2023. For Unix-type OSes that use RPATH it's load bearing.

Sean (Jul 11 2024 at 17:23):

when I built, lief is actually the only bext that had an issue. gcc7 is old but not that old... The issue is lief actually has c++17 code that is not strictly c++17-compliant but later gcc's decided to support anyways because someone got the docs wrong.

Sean (Jul 11 2024 at 17:23):

starseeker (Jul 11 2024 at 17:24):

Hmm. I'm actually surprised to hear gcc7 worked with Manifold and OpenNURBS. Did the full Appleseed stack and Qt also succeed?

Sean (Jul 11 2024 at 17:24):

starseeker (Jul 11 2024 at 17:24):

You might see if the upstream LIEF will take a pull request - it's actively maintained and the author has been reasonably responsive.

Sean (Jul 11 2024 at 17:24):

Sean (Jul 11 2024 at 17:25):

given gcc accommodated it, I wouldn't be surprised if they don't care. It's a bit of syntactic sugar so they don't have to manually declare a std::map size in their templatization.

Sean (Jul 11 2024 at 17:26):

Sean (Jul 11 2024 at 17:27):

also some pedantic issues that I'm surprised even current gcc wasn't barking on (extra trailing semicolons after a macro that has the semi)

starseeker (Jul 11 2024 at 17:29):

Huh. Well, we can do the patch for now if you think that's better - I might try making a PR later to see if they'll go for it.

Sean (Jul 11 2024 at 17:32):

I was actually thinking of either putting a version check on the compiler, just so the message isn't some syntax issue later (e.g., require gcc8 if it's gcc) or have a toggle to disable lief so only dev builds will run (i.e., for testing), but not relocated installs.

Sean (Jul 11 2024 at 17:33):

I have a partial patch, but like I said -- I gave up after a couple hours patching. There's more edits needed.

starseeker (Jul 11 2024 at 17:33):

Ah - OK, if you didn't get it all the way there, then we should file an Issue and see what they say.

Sean (Jul 11 2024 at 17:33):

More thinking how it's managed for someone else trying to build and hitting the error since it's still a current+default OS environment.

starseeker (Jul 11 2024 at 17:34):

We might be able to fall back to the older patchelf we had in the repo if the LIEF build fails...

Sean (Jul 11 2024 at 17:35):

starseeker (Jul 11 2024 at 17:35):

Sean (Jul 11 2024 at 17:35):

starseeker (Jul 11 2024 at 17:36):

Sean (Jul 11 2024 at 17:38):

Cool, thanks. So I'm not going nuts -- it's probably been that long since I compiled on one of the farm machines.

Sean (Jul 11 2024 at 17:39):

Still have a dream of getting the whole farm kicking off a build at least once a day, but that'll probably require more than Github runners to manage.

starseeker (Jul 11 2024 at 17:43):

FYA, even dev builds won't work without either LIEF or patchelf - bext installs into a target directory, and then the BRL-CAD configure process copies from that target and adjusts the paths accordingly to run locally in the BRL-CAD build. Since bext doesn't know anything about any BRL-CAD builds, it can't target the build directory as its install target.

starseeker (Jul 11 2024 at 17:46):

I suppose one way around it would be to have all the bext outputs install as system installs and then have BRL-CAD find everything it needs from system install locations via find_package, but we're not currently set up to have bext outputs install that way. It'd be an epic mess to clean up afterwards, and all too likely to nuke some system libs (particularly when we add USE_APPLESEED to the mix.) I'd have to test that in a VM to try and get it working.

starseeker (Jul 11 2024 at 17:48):

A middle ground might be to support targeting something like /usr/brlcad/bext-<sha1> or something as an output target, and then teach BRL-CAD's find_package calls to also look in that location by default.

Sean (Jul 11 2024 at 17:50):

starseeker (Jul 11 2024 at 17:50):

Sean (Jul 11 2024 at 17:52):

I'm more thinking about user that can't install into or modify /usr -- like the cfarm case. If they get a build working at all for their local use case. They're probably kicking tires.

starseeker (Jul 11 2024 at 17:54):

If patchelf builds that might be the easiest answer for older compilers? I know it's GPL, but we're not distributing it and we do have a non-GPL alternative as well...

Sean (Jul 11 2024 at 17:54):

If there's a workaround we could give someone, something like:
export LD_LIBRARY_PATH=/home/morrison/myapps/lib:$LD_LIBRARY_PATH
cmake .. -DBRLCAD_BUNDLED_LIBS=ON -DCMAKE_INSTALL_PREFIX=/home/morrison/myapps -DBRLCAD_DISABLE_RELOCATION=ON

Sean (Jul 11 2024 at 17:55):

I mean, I liked your goal of getting GPL out of the tree. patchelf set a bad precedent for anything blindly scanning. we have to explain it.

Sean (Jul 11 2024 at 17:56):

starseeker (Jul 11 2024 at 17:56):

Hmm... well, I can add the disable relocation part easily enough, but I definitely don't know what will happen with the find_package logic even if the LD_LIBRARY_PATH part works.

Sean (Jul 11 2024 at 17:56):

starseeker (Jul 11 2024 at 17:57):

find_package knows a few very specific places to look - I don't know whether it takes LD_LIBRARY_PATH into account at the CMake level or not. I definitely don't check it myself.

Sean (Jul 11 2024 at 17:57):

starseeker (Jul 11 2024 at 17:57):

Oh, you mean that level of intervention. Yeah, if you wanted to brute force it that hard you might be able to.

Sean (Jul 11 2024 at 17:57):

LD_LIBRARY_PATH will just be runtime checking, or calling into tools that were build and put somewhere -- the bit lief is making work by default.

Sean (Jul 11 2024 at 17:59):

The idea being that there'd be some flag that disables elf editing, which means those binaries might not run right during compilation, so LD_LIBRARY_PATH to the rescue.

Sean (Jul 11 2024 at 17:59):

starseeker (Jul 11 2024 at 18:01):

Well, it'd be in BRLCAD_ExternalDeps.cmake where we'd need such a flag. I can see about adding one quick, if that'll help, but I don't have time to test it thoroughly right now - I need to rework the facetize -r processing to not kick off so many subprocesses when there are a ton of regions.

Sean (Jul 11 2024 at 18:04):

For what it's worth and just more data points -- I tried five hosts and all five failed... One due to git submodules not working during the bext checkout, one due to tktable build error (Mac), one due to cmake 3.15 instead of 3.18, one due to a librt symbol issue, and the last being the lief issue.

starseeker (Jul 11 2024 at 18:05):

Sean (Jul 11 2024 at 18:05):

Granted, these are not in our usual testing vein, except for the Mac -- that one was surprising.

Sean (Jul 11 2024 at 18:06):

starseeker (Jul 11 2024 at 18:07):

1f357c9729 is when it happened. After the bump we added a few more 3.18 bits: c237cdd9

Sean (Jul 11 2024 at 18:09):

starseeker (Jul 11 2024 at 18:12):

starseeker (Jul 11 2024 at 18:14):

The librt symbol failure is a bit worrying. The git submodules one would be if it's reproducible and not just some network failure...

Sean (Jul 11 2024 at 18:21):

The librt one is the ancient one that shouldn't be an issue if paths are specified right up and down the stack -- could be an OS config issue or something else. I haven't dug yet.

Sean (Jul 11 2024 at 18:22):

The git one appears to be some incompatibility between the versions of cmake and git.

starseeker (Jul 11 2024 at 18:22):

Sean (Jul 11 2024 at 18:23):

Sean (Jul 11 2024 at 18:26):

**********************************************************
*** Configuring BRL-CAD Release 7.38.3, Build 20240710 ***
**********************************************************
-- Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY OPENGL_INCLUDE_DIR)
-- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
-- Could NOT find MPI (missing: MPI_C_FOUND C)
X11 detected and enabled
-- Performing Test HAVE_WORKING_REALPATH
-- Performing Test HAVE_WORKING_REALPATH - Failed
Attempting to prepare our own version of the bext dependencies

BRLCAD_EXT_SOURCE_DIR: /home/sean/brlcad.main/.build/bext
BRLCAD_EXT_BUILD_DIR: /home/sean/brlcad.main/.build/bext_build
/home/gitlost/bin/cmake -S /home/sean/brlcad.main/.build/bext -B /home/sean/brlcad.main/.build/bext_build --DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/sean/brlcad.main/.build
usage: git submodule [--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
   or: git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] init [--] [<path>...]
   or: git submodule [--quiet] deinit [-f|--force] (--all| [--] <path>...)
   or: git submodule [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--[no-]recommend-shallow] [--reference <repository>] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
   or: git submodule [--quiet] foreach [--recursive] <command>
   or: git submodule [--quiet] sync [--recursive] [--] [<path>...]
   or: git submodule [--quiet] absorbgitdirs [--] [<path>...]
CMake Error at /home/gitlost/share/cmake-3.28/Modules/ExternalProject.cmake:3238 (message):
  No download info given for 'PATCH_BLD' and its source directory:

   /home/sean/brlcad.main/.build/bext/patch/patch

  is not an existing non-empty directory.  Please specify one of:

   * SOURCE_DIR with an existing non-empty directory
   * DOWNLOAD_COMMAND
   * URL
   * GIT_REPOSITORY
   * SVN_REPOSITORY
   * HG_REPOSITORY
   * CVS_REPOSITORY and CVS_MODULE
Call Stack (most recent call first):
  /home/gitlost/share/cmake-3.28/Modules/ExternalProject.cmake:4422 (_ep_add_download_command)
  patch/CMakeLists.txt:35 (ExternalProject_Add)


-- Configuring incomplete, errors occurred!
CMake Error at misc/CMake/BRLCAD_Util.cmake:90 (_message):
  Unable to successfully configure bext dependency repository for building
Call Stack (most recent call first):
  misc/CMake/BRLCAD_EXT_Setup.cmake:218 (message)
  misc/CMake/BRLCAD_ExternalDeps.cmake:121 (brlcad_ext_setup)
  CMakeLists.txt:1989 (include)

sean@gcc111:[/home/sean/brlcad.main/.build]cmake .. -DBRLCAD_BUNDLED_LIBS=ON -DCMAKE_BUILD_TYPE=Release
CMAKE_SOURCE_DIR: /home/sean/brlcad.main
CMAKE_BINARY_DIR: /home/sean/brlcad.main/.build
CMake Warning at CMakeLists.txt:208 (message):
  BRL-CAD requires a source for external components, but no BRLCAD_EXT_DIR is
  set.  To use a pre-compiled set of components, set BRLCAD_EXT_DIR to a
  directory location containing the install and noinstall folders (the
  outputs produced by building https://github.com/BRL-CAD/bext).


CMake Warning at CMakeLists.txt:210 (message):
  Because no BRLCAD_EXT_DIR was successfully configured, BRL-CAD will attempt
  to download, configure and build its own bext copy locally during the
  configure process.


**********************************************************
*** Configuring BRL-CAD Release 7.38.3, Build 20240711 ***
**********************************************************
-- Could NOT find OpenGL (missing: OPENGL_opengl_LIBRARY OPENGL_glx_LIBRARY OPENGL_INCLUDE_DIR)
-- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
-- Could NOT find MPI (missing: MPI_C_FOUND C)
X11 detected and enabled
-- Performing Test HAVE_WORKING_REALPATH
-- Performing Test HAVE_WORKING_REALPATH - Failed
Attempting to prepare our own version of the bext dependencies

Cloning into 'bext'...
warning: templates not found in /home/avar/share/git-core/templates
git: 'remote-https' is not a git command. See 'git --help'.
CMake Error at misc/CMake/BRLCAD_Util.cmake:90 (_message):
  bext directory /home/sean/brlcad.main/.build/bext is not present
Call Stack (most recent call first):
  misc/CMake/BRLCAD_EXT_Setup.cmake:141 (message)
  misc/CMake/BRLCAD_ExternalDeps.cmake:121 (brlcad_ext_setup)
  CMakeLists.txt:1989 (include)

starseeker (Jul 11 2024 at 18:29):

@Sean It looks like the newer git wasn't built with https support? The clone line would be git clone -b RELEASE https://github.com/BRL-CAD/bext.git

starseeker (Jul 11 2024 at 18:29):

starseeker (Jul 11 2024 at 18:36):

I'm not sure exactly what the older git doesn't like... presumably one of the git commands in git_submodule_init

starseeker (Jul 11 2024 at 18:36):

starseeker (Jul 11 2024 at 18:37):

Sean (Jul 11 2024 at 18:38):

Yeah, I realized that later -- I'm scavenging builds because building git is a pita

Sean (Jul 11 2024 at 18:38):

starseeker (Jul 11 2024 at 18:39):

We could do a git version check in that function and use a simpler command for git versions without the single-branch option, or just nix it - I was trying everything I could think of to save space in that shallow cloning mode, but if it breaks except with very new Git...

Sean (Jul 11 2024 at 18:39):

starseeker (Jul 11 2024 at 18:40):

starseeker (Jul 11 2024 at 18:42):

starseeker (Jul 11 2024 at 18:43):

Can you run the submodule update line from bext/CMakeLists.txt:295 manually and see which option is at fault?

Sean (Jul 11 2024 at 19:26):

Sean (Jul 11 2024 at 19:28):

system-provided git 2.20.4 from /opt/freeware, and cmake 3.28.1. didn't use that earlier because the system-provided cmake is 3.16, but put just git into PATH with the newer cmake

Sean (Jul 11 2024 at 19:36):

starseeker (Jul 11 2024 at 19:37):

If you got a clone of bext in the build directory, you should be able to manually test getting a submodule updated and see which option is the problem?

Sean (Jul 11 2024 at 19:38):

starseeker (Jul 11 2024 at 19:39):

Sean (Jul 11 2024 at 19:44):

Sean (Jul 11 2024 at 19:45):

I pushed a change since it worked, but probably not right -- looks like it pushed to RELEASE?

starseeker (Jul 11 2024 at 19:48):

Ah - yeah, the checkout done by BRL-CAD itself is the RELEASE branch, for stability sake. Fine in this case since it wasn't working previously. I did the same thing on main, so it should be fine.

starseeker (Jul 11 2024 at 19:48):

Sean (Jul 11 2024 at 19:51):

[ 22%] Built target libnmg
[ 28%] Built target librt-obj
[ 28%] Built target librt
[ 28%] Built target gen-attributes-file
[ 28%] Generating attr_std_list.xml
./gen-attributes-file: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /home/sean/brlcad.main/.build/lib/libopenNURBS.so.2023.12.13)
./gen-attributes-file: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /home/sean/brlcad.main/.build/lib/libassimp.so.5)
./gen-attributes-file: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /home/sean/brlcad.main/.build/lib/libgeogram.so.1)
make[2]: *** [doc/docbook/system/man5/CMakeFiles/attr_std_list_xml.dir/build.make:74: doc/docbook/system/man5/attr_std_list.xml] Error 1
make[1]: *** [CMakeFiles/Makefile2:48715: doc/docbook/system/man5/CMakeFiles/attr_std_list_xml.dir/all] Error 2
make: *** [Makefile:166: all] Error 2
sean@gcc188:~/brlcad.main/.build> ls -la ./doc/docbook/system/man5/gen-attributes-file
-rwxr-xr-x 1 sean users 809056 Jul 11 07:33 ./doc/docbook/system/man5/gen-attributes-file
sean@gcc188:~/brlcad.main/.build> ldd ./doc/docbook/system/man5/gen-attributes-file
./doc/docbook/system/man5/gen-attributes-file: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /home/sean/brlcad.main/.build/lib/libopenNURBS.so.2023.12.13)
./doc/docbook/system/man5/gen-attributes-file: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /home/sean/brlcad.main/.build/lib/libassimp.so.5)
./doc/docbook/system/man5/gen-attributes-file: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /home/sean/brlcad.main/.build/lib/libgeogram.so.1)
        linux-vdso.so.1 (0x00007fffc7e3e000)
        librt.so.20 => /home/sean/brlcad.main/.build/lib/librt.so.20 (0x00007f94ecb33000)
        libbrep.so.20 => /home/sean/brlcad.main/.build/lib/libbrep.so.20 (0x00007f94ec9f7000)
        libnmg.so => /home/sean/brlcad.main/.build/lib/libnmg.so (0x00007f94ec90b000)
        libbv.so.20 => /home/sean/brlcad.main/.build/lib/libbv.so.20 (0x00007f94ec8d3000)
        libbg.so.20 => /home/sean/brlcad.main/.build/lib/libbg.so.20 (0x00007f94ec811000)
        libbn.so.20 => /home/sean/brlcad.main/.build/lib/libbn.so.20 (0x00007f94ec7ba000)
        libbu.so.20 => /home/sean/brlcad.main/.build/lib/libbu.so.20 (0x00007f94ea0a3000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f94ea08a000)
        liblmdb.so => /home/sean/brlcad.main/.build/lib/liblmdb.so (0x00007f94ea073000)
        libuuid.so.1 => /usr/lib64/libuuid.so.1 (0x00007f94ea06b000)
        libopenNURBS.so.2023.12.13 => /home/sean/brlcad.main/.build/lib/libopenNURBS.so.2023.12.13 (0x00007f94e9777000)
        libmanifold.so.2 => /home/sean/brlcad.main/.build/lib/libmanifold.so.2 (0x00007f94e965b000)
        libassimp.so.5 => /home/sean/brlcad.main/.build/lib/libassimp.so.5 (0x00007f94e8b60000)
        libgeogram.so.1 => /home/sean/brlcad.main/.build/lib/libgeogram.so.1 (0x00007f94e8523000)
        libregex_brl.so.1 => /home/sean/brlcad.main/.build/lib/libregex_brl.so.1 (0x00007f94e8515000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f94e82d0000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f94e8182000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f94e815e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f94e813a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f94e7f43000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f94ed002000)
        libz_brl.so.1 => /home/sean/brlcad.main/.build/lib/libz_brl.so.1 (0x00007f94e7f26000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f94e7f1a000)
        libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007f94e7ec8000)

starseeker (Jul 11 2024 at 19:53):

Sean (Jul 11 2024 at 19:57):

They must have. The system default is that gcc 7.5, but cmake was configured with a gcc 14 build. Looks like the deps compiled with 14 but while running gen-attributes-file it's finding/using the older system libs first.

Sean (Jul 11 2024 at 20:03):

Hm, or actually maybe the opposite. A custom hello world seems correct, loads and runs. So maybe something with bext libs.

Sean (Jul 11 2024 at 20:12):

@starseeker Is there a way to keep the bext and bext_build directories around once build is complete?

starseeker (Jul 11 2024 at 21:08):

starseeker (Jul 11 2024 at 21:09):

If you want to avoid BRL-CAD cleaning them up you can comment out lines 246 and 249 in BRLCAD_EXT_Setup.cmake

Sean (Jul 11 2024 at 21:33):

I found another workaround. The error CXXABI error was coming from using gcc14 which is bleeding edge from one of the gcc devs, but the system-installed one was one minor bump off. Adding an LD_LIBRARY_PATH to one of the newer libstdc++'s appears to be working like a charm.

Sean (Jul 11 2024 at 21:37):

What I think is happening is bext builds just fine (gcc14, products depend on its libstdc++ which is not installed and their rpaths are oblivious), but then when main code compiles, something has added /usr/lib64 to the search path and it's overriding, causing the link-time errors.

Sean (Jul 11 2024 at 22:25):

Sean (Jul 12 2024 at 05:16):

@starseeker a make check on trunk on that system is reporting three failures, all appear to be triangulation/facetization-related:
916 - ged_test_drawing_basic (Failed)
918 - ged_test_drawing_lod (Failed)
919 - ged_test_drawing_select (Failed)

starseeker (Jul 12 2024 at 11:43):

Any chance you could try a stand-alone facetize on that system to see what the error is? IIRC most of those tests are working with moss.g, so it's gotta be something pretty basic.

Sean (Jul 13 2024 at 15:52):

I can, but does "make check" work for you? Strange for that to be platform-specific.

Sean (Jul 13 2024 at 16:04):

mged> facetize all.g all.bot
Attempting to triangulate 6 solids... FAILED.
Attempting to triangulate 3 solids... FAILED.
Attempting to triangulate tor... FAILED.
Attempting to triangulate 2 solids... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate 3 solids... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate 2 solids... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.
Attempting to triangulate tor... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.
Attempting to triangulate tor... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.
Attempting to triangulate tor... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.

Primitive tessellation summary:

6 object(s) failed.

Sean (Jul 13 2024 at 16:05):

mged> facetize --nmg-booleval all.g all.bot
mged> l all.bot
all.bot:  Bag of triangles (BOT)
        461 vertices, 902 faces (counter-clockwise)
        This is a solid object (not just a surface)
    use -v (verbose) for all data

Sean (Jul 13 2024 at 16:08):

mged> facetize --methods=CM all.g all.bot
Attempting to triangulate tor... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.

Primitive tessellation summary:

6 object(s) failed.
mged> facetize --methods=SPSR all.g all.bot
Attempting to triangulate tor... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.

Primitive tessellation summary:

6 object(s) failed.
mged> facetize --methods=CO3NE all.g all.bot
Attempting to triangulate tor... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.

Primitive tessellation summary:

6 object(s) failed.
mged> facetize --methods=NMG all.g all.bot
Attempting to triangulate 6 solids... FAILED.
Attempting to triangulate 3 solids... FAILED.
Attempting to triangulate tor... FAILED.
Attempting to triangulate 2 solids... FAILED.
Attempting to triangulate LIGHT... FAILED.
Attempting to triangulate ellipse.s... FAILED.
Attempting to triangulate 3 solids... FAILED.
Attempting to triangulate cone.s... FAILED.
Attempting to triangulate 2 solids... FAILED.
Attempting to triangulate box.s... FAILED.
Attempting to triangulate platform.s... FAILED.

Primitive tessellation summary:

6 object(s) failed.

Matteo Balice (Jul 13 2024 at 18:38):

[ 75%] Performing build step for 'TK_BLD'
CMake Error at /Users/matteobalice/Desktop/rt_volume/build/src/other/ext/TK_BLD-prefix/src/TK_BLD-stamp/TK_BLD-build-Release.cmake:37 (message):
  Command failed: 2

   'make' '-j4'

  See also

    /Users/matteobalice/Desktop/rt_volume/build/src/other/ext/TK_BLD-prefix/src/TK_BLD-stamp/TK_BLD-build-*.log


-- stdout output is:

-- stderr output is:
/Users/matteobalice/Desktop/rt_volume/build/src/other/ext/TK_BLD-prefix/src/TK_BLD/unix/../generic/tkFont.c:419:9: warning: variable 'fontsLeft' set but not used [-Wunused-but-set-variable]
    int fontsLeft = 0;
        ^
1 warning generated.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /Users/matteobalice/Desktop/rt_volume/build/lib/libtclstub8.6.a: No such file or directory
clang: error: no such file or directory: '__TEXT'
clang: error: no such file or directory: '__info_plist'
make[4]: *** [libtk8.6.dylib] Error 1

CMake Error at /Users/matteobalice/Desktop/rt_volume/build/src/other/ext/TK_BLD-prefix/src/TK_BLD-stamp/TK_BLD-build-Release.cmake:47 (message):
  Stopping after outputting logs.


make[3]: *** [src/other/ext/TK_BLD-prefix/src/TK_BLD-stamp/TK_BLD-build] Error 1
make[2]: *** [src/other/ext/CMakeFiles/TK_BLD.dir/all] Error 2
make[1]: *** [src/rt/CMakeFiles/rt_trainneural.dir/rule] Error 2
make: *** [rt_trainneural] Error 2

Matteo Balice (Jul 13 2024 at 18:39):

Matteo Balice (Jul 13 2024 at 18:42):

Sean (Jul 14 2024 at 05:14):

@Matteo Balice thanks for reporting, but some questions -- what is your source checkout from? That build appears to be not a current main checkout... maybe a source tarball or some branch?

Since you're doing active development, you should be on a cloned main tree. There's no longer a src/other in the latest tree.

Matteo Balice (Jul 14 2024 at 06:45):

Matteo Balice (Jul 14 2024 at 11:06):

Ok I have cloned the last source code and I am finally able to run on my mac M1 after some issues...
I only have one last issue: here I try to plot the rendering but I got these issues and I can't see the render in a window like I do in windows:

Metal is available.
db is /Users/matteobalice/Desktop/rt_volume/build/share/db/moss.g
obj is all.g
0x128280038 TOL 5.000000e-04 (sq=2.500000e-07) perp=1.000000e-06, para=9.999990e-01
rt_gettrees(ERROR) FAILED
GETTREE: cpu = 3.8e-05 sec, elapsed = 0.00003 sec

Additional #malloc=2229, #free=157, #realloc=14 (2072 retained)
BRL-CAD Release 7.38.3 The BRL-CAD Optical Shader Library
Sun, 14 Jul 2024 09:42:04 UTC, Compilation 1
@Air-di-Matteo.homenet.telecomitalia.it
bu_shmget failed, errno=22
bu_shmget: Invalid argument
ogl_getmem: Unable to attach to shared memory, using private
fb_ogl_open: double buffering not available. Using single buffer.
fb_ogl_open: Couldn't find an appropriate visual. Exiting.
fb_open: can't open device "/dev/ogl", ret=-1.
rt: can't open frame buffer
fail to open fb
...................Frame 0...................
PREP: cpu = 0.000234 sec, elapsed = 0.00047 sec

Additional #malloc=1425, #free=1202, #realloc=18 (223 retained)
NUBSP: 36 cut, 37 box (37 empty)
Tree: 6 solids in 6 regions
Model: X(-50, 90), Y(-70, 70), Z(-24, 63)
View: 1.05251e-14 azimuth, -9.69727e-15 elevation off of front view
Orientation: 0.5, 0.5, 0.5, 0.5
Eye_pos: 172.92, 2.80909e-14, 19.5
Size: 216.261mm
Grid: (0.844771, 0.844771) mm, (256, 256) pixels
Beam: radius=0.422386 mm, divergence=0 mm/1mm
Mode: scanline-per-CPU buffering

Additional #malloc=300, #free=285, #realloc=9 (15 retained)
13642 solid/ray intersections: 7724 hits + 5918 miss
pruned 56.6%: 48541 model RPP, 9217 dups skipped, 4655 solid RPP
Frame 0: 65536 pixels in 0.02 sec = 4100100.10 pixels/sec
Frame 0: 66864 rays in 0.02 sec = 4183183.18 rays/sec (RTFM)
Frame 0: 66864 rays in 0.02 sec = 4183183.18 rays/CPU_sec
Frame 0: 66864 rays in 0.02 sec = 4041830.38 rays/sec (wallclock)

Matteo Balice (Jul 14 2024 at 11:07):

bu_shmget failed, errno=22
bu_shmget: Invalid argument
ogl_getmem: Unable to attach to shared memory, using private
fb_ogl_open: double buffering not available. Using single buffer.
fb_ogl_open: Couldn't find an appropriate visual. Exiting.
fb_open: can't open device "/dev/ogl", ret=-1.
rt: can't open frame buffer
fail to open fb

Sean (Jul 14 2024 at 13:28):

That’s a known current issue with the OpenGL framebuffer. Add -F/dev/X to get it to use X11 instead.

Sean (Jul 14 2024 at 13:29):

Vidit Jain (Jul 23 2024 at 16:11):

@Sean The site where documentation for setting up BRL-CAD is down.link
Screenshot-1.png

Sean (Jul 24 2024 at 04:40):

@Vidit Jain thanks for reporting. Looks like it was a temporary issue -- the database resets periodically and is big enough that sometimes it takes a few seconds to spin back up.

Sean (Jul 25 2024 at 02:52):

So I finally caved in and bought a new SSD to accommodate the new external build setup... Had to really. Everything enabled is 169GB for all sources, 46GB for a debug build, and similar for release (but build failed, so don't yet have a precise number). That's over 250GB for externals, plus another 1-20GB for each main repo build. Fun!

Sean (Jul 25 2024 at 02:56):

On the plus side, the SSD is actually about 5x faster than my internal SSD drive, and so nice to finally have breathing room again.

Sean (Jul 26 2024 at 21:12):

@starseeker So I've tried three times now to get a clean test on gcc188 and keep hitting this:

[ 63%] Performing build step for 'TIFF_BLD'
-- TCL_BLD build command succeeded.  See also /home/sean/brlcad.main/.build/bext_build/tcl/TCL_BLD-prefix/src/TCL_BLD-stamp/TCL_BLD-build-*.log
[ 63%] Performing install step for 'TCL_BLD'
CMake Error at /home/sean/brlcad.main/.build/bext_build/tcl/TCL_BLD-prefix/src/TCL_BLD-stamp/TCL_BLD-install-Release.cmake:37 (message):
  Command failed: 2

   'make' 'install'

  See also

    /home/sean/brlcad.main/.build/bext_build/tcl/TCL_BLD-prefix/src/TCL_BLD-stamp/TCL_BLD-install-*.log


-- stdout output is:
Warning: tclStubInit.c may be out of date.
Developers may want to run "make genstubs" to regenerate.
This warning can be safely ignored, do not report as a bug!

-- stderr output is:
make[3]: *** read jobs pipe: Bad file descriptor.  Stop.
make[3]: *** Waiting for unfinished jobs....

starseeker (Jul 26 2024 at 21:13):

Christopher (Jul 26 2024 at 21:15):

Sean (Jul 26 2024 at 21:18):

Sean (Jul 26 2024 at 21:19):

If I cd to the build dir and just run make, it seems to build, but then of course re-running cmake re-runs install and it barfs again.

Christopher (Jul 26 2024 at 21:20):

I built bext separately (non-parallel) and then could do a brlcad build as normal with -DBRLCAD_EXT_DIR

Sean (Jul 26 2024 at 21:26):

Where is the parallelism specified in the auto form? I've hunted and can't seem to find it anywhere I would expect it to be.

Christopher (Jul 26 2024 at 21:26):

starseeker (Jul 26 2024 at 21:28):

starseeker (Jul 26 2024 at 21:29):

You can override that at the CMake level up top by specifying -DBRLCAD_EXT_PARALLEL=1 - that's what I do in the Github CI builds, IIRC

Sean (Jul 26 2024 at 21:30):

If I jump into the bext_build dir and kick things off manually, it does seem to be specific to Tcl and just Tcl. Something timing related or something getting clobbered or not specified right.

starseeker (Jul 26 2024 at 21:31):

To my recollection I've only hit that parallelism problem in VMs - on physical hardware it doesn't seem to trigger, for whatever reason (at least for me...)

starseeker (Jul 26 2024 at 21:33):

Honestly, on bad days I'm tempted to re-apply my old Tcl CMake build as a patch in bext - the Tcl build is also incompatible somehow with being run inside Visual Studio

Sean (Jul 26 2024 at 21:43):

starseeker (Jul 26 2024 at 22:10):

starseeker (Jul 26 2024 at 22:12):

Sean (Jul 26 2024 at 22:15):

Don't know if gcc188 is virtualized, not that it should matter, but it's a rather beefy VM if it is. Cmake did succeed with -DBRLCAD_EXT_PARALLEL=1 so definitely something related with the fact that it's passing through to a make build.

Sean (Jul 26 2024 at 22:16):

Now what's strange is that parallel is involved given this is the install step. Are we running make install in parallel? That's probably not something we should be doing.

Sean (Jul 26 2024 at 22:19):

Don't see install in BRLCAD_EXT_Setup.cmake ... so doesn't seem to be that setting?

Sean (Jul 26 2024 at 22:21):

Looks like that's the only place BRLCAD_EXT_PARALLEL is used, so it must be one of them... huh.

starseeker (Jul 26 2024 at 22:23):

The BRLCAD_EXT_Setup.cmake line 234 triggers the build of the bext superproject. The Tcl build was getting it's parallel setting (before I yanked it) from the pcnt variable in bext, which is set in bext/CMakeLists.txt:172

starseeker (Jul 26 2024 at 22:25):

So that's one issue, looks like - anything using pcnt would try to be parallel regardless.

starseeker (Jul 26 2024 at 22:26):

so maybe the Tcl build is OK in parallel ONLY if nothing else is trying to build on the system at the time?

starseeker (Jul 26 2024 at 22:27):

BRLCAD_EXT_PARALLEL=1 was reducing how many ExternalProject_Add targets got fired off, but wasn't turning off the parallelism of the Tcl build itself

starseeker (Jul 26 2024 at 22:28):

So I guess the question is whether yanking the -j$pcnt flag from the Tcl build will make it OK to build the superbuild project in parallel, or if Tcl will be unhappy even if it's building non-parallel itself

starseeker (Jul 26 2024 at 22:33):

As a heads-up @Sean , if I recall correctly Chris had to use the renaming trick for librt to avoid a linking conflict of some sort.

starseeker (Jul 26 2024 at 22:34):

Sean (Jul 26 2024 at 22:34):

I'd already tried manually forcing pcnt to 1 and was still failing -- looks like that flag is only build, not install.

Sean (Jul 26 2024 at 22:35):

Christopher (Jul 26 2024 at 22:36):

yes, librt. Sean, if you look in my brlcad directory, I have a COMPILE_NOTES text file that I was keeping my tricks in

starseeker (Jul 26 2024 at 22:36):

I don't get it then, because the bext/tcl/CMakeLists.txt:75 instruction is just "make install"...

Sean (Jul 26 2024 at 22:37):

Sean (Jul 26 2024 at 22:41):

I mean you can see in the log, it's only on the install step. Perhaps important that the "make -j8" step in bext_build actually kicks off build and install phases internally..

Sean (Jul 26 2024 at 22:42):

Warning: tclStubInit.c may be out of date.
Developers may want to run "make genstubs" to regenerate.
This warning can be safely ignored, do not report as a bug!

starseeker (Jul 26 2024 at 22:42):

Sean (Jul 26 2024 at 22:44):

If make and install are kicking off, might be the case that the build make returns but isn't done writing to disk or something. The make install runs, generates tclStubInit.c to satisfy dependencies, writes out, and then it's overwritten with the original build make, thus invalidating it datewise.

starseeker (Jul 26 2024 at 22:45):

Sean (Jul 26 2024 at 22:47):

What about manually injecting a "make genstubs" before "make install" runs as a custom command. That should deal with any potential race I'd think.

Sean (Jul 26 2024 at 22:47):

starseeker (Jul 26 2024 at 22:47):

Sean (Jul 27 2024 at 01:48):

Sean (Jul 27 2024 at 02:46):

Committed a fix. Turns out the clue was that build worked but install did not, and that I could get build to also fail, and then when I got build+install working, tk failed the same way. Issue was make jobserver, so fix was actually to add -j to all the make calls which turns it off in this recursive mode.

Sean (Jul 27 2024 at 03:30):

CMake Error at /Volumes/X10/brlcad.bext/.build.release/qt/qt_build.cmake:18 (message):
  Qt build failed: [ 0%] Built target syncqt

  [ 1%] Built target Core_lib_pri

  [ 1%] Built target qmodule_pri

  Error copying directory from
  "/Volumes/X10/brlcad.bext/.build.release/qt/qt6-build/include/QtCore/.syncqt_staging"
  to
  "/Volumes/X10/brlcad.bext/.build.release/qt/qt6-build/lib/QtCore.framework/Versions/A/Headers".


  make[5]: *** [src/corelib/CMakeFiles/Core_copy_fw_sync_headers] Error 1

  make[4]: *** [src/corelib/CMakeFiles/Core_copy_fw_sync_headers.dir/all]
  Error 2

  make[3]: *** [all] Error 2

Sean (Jul 27 2024 at 03:31):

Sean (Jul 28 2024 at 23:59):

Can confirm, build appears to be working and passes make check on the cfarm 188 machine (Linux x86_64, openSUSE Leap 15.5)

Stream: brlcad

Topic: build

Abhishek Prasad (Dec 03 2017 at 07:59):

Sean (Dec 03 2017 at 08:47):

Abhishek Prasad (Dec 03 2017 at 09:24):

Erik (Dec 03 2017 at 12:53):

Abhishek Prasad (Dec 03 2017 at 13:56):

Sean (Dec 03 2017 at 16:53):

Sean (Dec 03 2017 at 16:54):

Abhishek Prasad (Dec 04 2017 at 04:56):

Sean (Dec 04 2017 at 14:43):

Sean (Dec 04 2017 at 14:44):

Sean (Dec 04 2017 at 14:44):

Sean (Dec 04 2017 at 14:45):

Abhishek Prasad (Dec 04 2017 at 15:45):

Naseef (Dec 04 2017 at 15:45):

Abhishek Prasad (Dec 04 2017 at 15:46):

Abhishek Prasad (Dec 04 2017 at 15:48):

Abhishek Prasad (Dec 04 2017 at 15:48):

Abhishek Prasad (Dec 04 2017 at 16:01):

Abhishek Prasad (Dec 04 2017 at 16:05):

Abhishek Prasad (Dec 04 2017 at 16:05):

Abhishek Prasad (Dec 04 2017 at 16:06):

Naseef (Dec 04 2017 at 16:07):

Abhishek Prasad (Dec 04 2017 at 16:11):

Naseef (Dec 04 2017 at 16:11):

Abhishek Prasad (Dec 04 2017 at 16:11):

Naseef (Dec 04 2017 at 16:11):

Abhishek Prasad (Dec 04 2017 at 16:12):

Abhishek Prasad (Dec 04 2017 at 16:12):

Naseef (Dec 04 2017 at 16:12):

Abhishek Prasad (Dec 04 2017 at 16:12):

Naseef (Dec 04 2017 at 16:12):

Abhishek Prasad (Dec 04 2017 at 16:13):

Naseef (Dec 04 2017 at 16:13):

Naseef (Dec 04 2017 at 16:13):

Sean (Dec 04 2017 at 16:20):

Sean (Dec 04 2017 at 16:21):

Sean (Dec 04 2017 at 16:22):

Naseef (Dec 04 2017 at 16:29):

Naseef (Dec 04 2017 at 16:29):

Sean (Dec 04 2017 at 16:29):

Abhishek Prasad (Dec 05 2017 at 04:04):

Rahil Malik (Dec 05 2017 at 09:45):

Abhishek Prasad (Dec 05 2017 at 09:49):

Rahil Malik (Dec 05 2017 at 10:07):

Rahil Malik (Dec 05 2017 at 10:07):

Rahil Malik (Dec 05 2017 at 10:08):

Mitesh (Dec 05 2017 at 11:15):

Mitesh (Dec 05 2017 at 11:15):

Daniel Rossberg (Dec 05 2017 at 11:18):

Rahil Malik (Dec 05 2017 at 14:51):

Rahil Malik (Dec 05 2017 at 14:52):

Rahil Malik (Dec 05 2017 at 14:54):

Daniel Rossberg (Dec 05 2017 at 14:58):

Rahil Malik (Dec 05 2017 at 15:00):

Rahil Malik (Dec 05 2017 at 15:01):

Daniel Rossberg (Dec 05 2017 at 15:03):

Daniel Rossberg (Dec 05 2017 at 15:04):

Rahil Malik (Dec 05 2017 at 15:06):

Rahil Malik (Dec 05 2017 at 15:06):

Daniel Rossberg (Dec 05 2017 at 15:07):

Rahil Malik (Dec 05 2017 at 15:08):

Rahil Malik (Dec 05 2017 at 15:09):

Daniel Rossberg (Dec 05 2017 at 15:10):

Rahil Malik (Dec 05 2017 at 15:15):

Daniel Rossberg (Dec 05 2017 at 15:15):

Daniel Rossberg (Dec 05 2017 at 15:18):

Daniel Rossberg (Dec 05 2017 at 15:21):

Rahil Malik (Dec 05 2017 at 15:22):

Rahil Malik (Dec 05 2017 at 15:23):

Daniel Rossberg (Dec 05 2017 at 15:27):

Rahil Malik (Dec 05 2017 at 15:28):

Daniel Rossberg (Dec 05 2017 at 15:30):

Rahil Malik (Dec 05 2017 at 15:30):

Rahil Malik (Dec 05 2017 at 15:30):

Rahil Malik (Dec 05 2017 at 15:31):

Daniel Rossberg (Dec 05 2017 at 15:32):

Rahil Malik (Dec 05 2017 at 15:42):

Daniel Rossberg (Dec 05 2017 at 15:44):