Vikram Atreya (Oct 12 2020 at 15:19): Vikram Atreya (Oct 12 2020 at 15:19):I downloaded the file from sourceforge and was following the readme. When i ran the below command I got the following error.
cmake .. -DBRLCAD_BUNDLED_LIBS=ON -DCMAKE_BUILD_TYPE=Release
CMake Error: The source directory "....../BRL-CAD_7.32.0_Linux_x86_64" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
Sumagna Das (Oct 12 2020 at 17:18):You are on windows?
Vikram Atreya (Oct 12 2020 at 17:24):No Im on ubuntu 18.04
Sumagna Das (Oct 12 2020 at 17:36):Ohh
Sumagna Das (Oct 12 2020 at 17:37):you are building it from the source i suppose then
Vikram Atreya (Oct 12 2020 at 17:38):Yeah , I downloaded the tar.gz and followed the instructions in the readme
Sumagna Das (Oct 12 2020 at 17:42):let me check it on my own computer.....
Sumagna Das (Oct 12 2020 at 17:42):i build it from the source so i dont know about the .tar.gz file
Sumagna Das (Oct 12 2020 at 17:48):wait a bit... my internet speed is not very good right now.
Sumagna Das (Oct 12 2020 at 17:49):so its taking some time to download the .tar.gz
Vikram Atreya (Oct 12 2020 at 17:49):Okay, no probs
Sumagna Das (Oct 12 2020 at 17:53):i see
Sumagna Das (Oct 12 2020 at 17:54):the .tar.gz you downloaded includes the prebuilt binaries
Sumagna Das (Oct 12 2020 at 17:56):it doesnt have to be built
Sumagna Das (Oct 12 2020 at 17:57):and you are trying to build it..
Sumagna Das (Oct 12 2020 at 17:57):@Vikram Atreya Do you want to build it from source?
Vikram Atreya (Oct 12 2020 at 18:09):Yeah,How do I build it from source ? :grimacing:
Sumagna Das (Oct 12 2020 at 18:10):you can follow this one -> https://brlcad.org/wiki/Building_from_SVN
Vikram Atreya (Oct 12 2020 at 18:11):Okay thanks
Sumagna Das (Oct 12 2020 at 18:13):if you need any help, tell us in #general or you can tell us here.....
Vikram Atreya (Oct 12 2020 at 19:27):I followed the steps in the link
The cmake .. worked fine
After that i ran the "make" command and this was the error
[ 11%] Building CXX object src/libbg/CMakeFiles/libbg-obj.dir/spsr/SPSR.cpp.o
/home/vikram/brlcad/src/libbg/spsr/SPSR.cpp:43:34: error: unknown option after ‘#pragma GCC diagnostic’ kind [-Werror=pragmas]
# pragma GCC diagnostic ignored "-Wclass-memaccess"
^~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
src/libbg/CMakeFiles/libbg-obj.dir/build.make:470: recipe for target 'src/libbg/CMakeFiles/libbg-obj.dir/spsr/SPSR.cpp.o' failed
make[2]: *** [src/libbg/CMakeFiles/libbg-obj.dir/spsr/SPSR.cpp.o] Error 1
CMakeFiles/Makefile2:6634: recipe for target 'src/libbg/CMakeFiles/libbg-obj.dir/all' failed
make[1]: *** [src/libbg/CMakeFiles/libbg-obj.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
How do i resolve this?
Daniel Rossberg (Oct 13 2020 at 06:39):Ubuntu 18.04 uses gcc version 7.4.0, but the class-memaccess option was introduced with version 8 (https://gcc.gnu.org/gcc-8/changes.html). If updating your OS isn't an option, you could remove this line and try again.
Vikram Atreya (Oct 13 2020 at 09:43):I updated my gcc to above version 8 and it solved the problem. Thanks!
starseeker (Oct 13 2020 at 13:21):Per @Daniel Rossberg 's identification of the source of the issue I added a guard in r77408 and r77409, so barring some other issue elsewhere in the code things should work now.
Jaidev (Oct 25 2020 at 15:57):cmake ..
* Configuring BRL-CAD Release 7.32.1, Build 20201025 *
**************
CMake Error at misc/CMake/BRLCAD_Util.cmake:96 (_message):
Installation directory (BRLCAD_INSTALL_PREFIX) is set to
/usr/brlcad/dev-7.32.1, but build type is set to Release!
Call Stack (most recent call first):
CMakeLists.txt:724 (message)
-- Configuring incomplete, errors occurred!
See also "/home/jaidev/brlcad/CMakeFiles/CMakeOutput.log".
See also "/home/jaidev/brlcad/CMakeFiles/CMakeError.log".
when i do cmake , this error occurs
starseeker (Oct 25 2020 at 16:57):What options are you passing to CMake?
Jaidev (Oct 25 2020 at 17:00):nothing following the readme for default only i did
cmake ..
starseeker (Oct 25 2020 at 17:02):From the source directory, or did you make a build directory?
Jaidev (Oct 25 2020 at 17:02):build directory
starseeker (Oct 25 2020 at 17:03):OK, one sec... I'm seeing a different odd behavior...
Jaidev (Oct 25 2020 at 17:04):Is this something about wrong in cmakelists.txt
starseeker (Oct 25 2020 at 17:04):We try to do some path management for CMAKE_INSTALL_PREFIX - I may have made some changes recently that aren't working
Jaidev (Oct 25 2020 at 17:06):i guess it won't run now for the time.
starseeker (Oct 25 2020 at 17:06):Try setting -DBRLCAD_INSTALL_PREFIX=/usr/brlcad/rel-7.32.1
Jaidev (Oct 25 2020 at 17:10):/home/jaidev/brlcad/build/CMakeTmp/dreport.c:38: error: expected '{' at end
of input
38 | }
|
make[1]: *** [CMakeFiles/cmTC_0d7b3.dir/build.make:66:
CMakeFiles/cmTC_0d7b3.dir/dreport.c.o] Error 1
make[1]: Leaving directory
'/home/jaidev/brlcad/build/CMakeTmp/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_0d7b3/fast] Error 2
Call Stack (most recent call first):
misc/CMake/BRLCAD_Util.cmake:561 (message)
CMakeLists.txt:733 (generate_dreport)
-- Configuring incomplete, errors occurred!
See also "/home/jaidev/brlcad/build/CMakeFiles/CMakeOutput.log".
same error occurs again
Jaidev (Oct 25 2020 at 17:10):cmake .. -DBRLCAD_INSTALL_PREFIX=/usr/brlcad/rel-7.32.1
starseeker (Oct 25 2020 at 17:13):OK, one sec...
starseeker (Oct 25 2020 at 17:18):Try r77650
starseeker (Oct 25 2020 at 17:18):(without -DBRLCAD_INSTALL_PREFIX)
starseeker (Oct 25 2020 at 17:19):@Jaidev That seems to give better behavior here.
Jaidev (Oct 25 2020 at 17:24):i don't get it
Jaidev (Oct 25 2020 at 17:24):r77650 with cmake???
starseeker (Oct 25 2020 at 17:28):The latest SVN BRL-CAD checkout.
starseeker (Oct 25 2020 at 17:29):So in your brlcad checkout directory, do "svn update"
Jaidev (Oct 25 2020 at 17:29):okkk doing
Jaidev (Oct 25 2020 at 17:29):i thought of downloading again
starseeker (Oct 25 2020 at 17:29):You should see it pull in some updates to the CMakeLists.txt file and RPath_Setup.cmake file
starseeker (Oct 25 2020 at 17:31):Once you have the updates, clear everything out of the build directory and try "cmake .." again
Jaidev (Oct 25 2020 at 17:32):yaa, i updated it
Jaidev (Oct 25 2020 at 17:32):Updated to revision 77650.
starseeker (Oct 25 2020 at 17:32):OK, let's see if that fixes it.
Jaidev (Oct 25 2020 at 17:33):cmake with any prefix
Jaidev (Oct 25 2020 at 17:33):or simply
cmake ..
starseeker (Oct 25 2020 at 17:33):right
Jaidev (Oct 25 2020 at 17:35):No, same error occurs again
starseeker (Oct 25 2020 at 17:36):The build type set to Release issue?
starseeker (Oct 25 2020 at 17:37):or the dreport error?
Jaidev (Oct 25 2020 at 17:37):/home/jaidev/brlcad/build/CMakeTmp/dreport.c:38: error: expected '{' at end
of input
38 | }
|
make[1]: *** [CMakeFiles/cmTC_fab9c.dir/build.make:66:
CMakeFiles/cmTC_fab9c.dir/dreport.c.o] Error 1
make[1]: Leaving directory
'/home/jaidev/brlcad/build/CMakeTmp/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_fab9c/fast] Error 2
Call Stack (most recent call first):
misc/CMake/BRLCAD_Util.cmake:561 (message)
CMakeLists.txt:705 (generate_dreport)
-- Configuring incomplete, errors occurred!
See also "/home/jaidev/brlcad/build/CMakeFiles/CMakeOutput.log".
starseeker (Oct 25 2020 at 17:37):can you post the contents of
/home/jaidev/brlcad/build/CMakeTmp/dreport.c
Jaidev (Oct 25 2020 at 17:37):yeah sure
Jaidev (Oct 25 2020 at 17:38): starseeker (Oct 25 2020 at 17:39):What gcc version are you using?
starseeker (Oct 25 2020 at 17:40):gcc -v
Jaidev (Oct 25 2020 at 17:40):gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
starseeker (Oct 25 2020 at 17:41):That's really strange - if you compile that file in isolation (gcc -o dreport dreport.c) does it build?
Jaidev (Oct 25 2020 at 17:42):CMake Error at misc/CMake/BRLCAD_Util.cmake:96 (_message):
Could not build time delta reporting utility: Change Dir:
/home/jaidev/brlcad/build/CMakeTmp/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make cmTC_927c8/fast && /usr/bin/make -f
CMakeFiles/cmTC_927c8.dir/build.make CMakeFiles/cmTC_927c8.dir/build
make[1]: Entering directory
'/home/jaidev/brlcad/build/CMakeTmp/CMakeFiles/CMakeTmp'
Jaidev (Oct 25 2020 at 17:43):this shows while i run cmake ..
starseeker (Oct 25 2020 at 17:43):Right - what about if you just compile the dreport.c file directly?
Jaidev (Oct 25 2020 at 17:44):let me see
starseeker (Oct 25 2020 at 17:44):Other question - what's in CMakeFiles/cmTC_927c8.dir/build.make
Jaidev (Oct 25 2020 at 17:48):In file included from /usr/local/include/corecrt.h:10,
from /usr/local/include/crtdefs.h:10,
from /usr/local/include/time.h:9,
from dreport-1603647601309.c:4:
/usr/local/include/_mingw.h:273:2: error: #error Only Win32 target is supported!
273 | #error Only Win32 target is supported!
Jaidev (Oct 25 2020 at 17:49):after i compile dreport.c
starseeker (Oct 25 2020 at 17:50):What on earth...
Jaidev (Oct 25 2020 at 17:50):this error occurs
starseeker (Oct 25 2020 at 17:50):OK, it's pulling a lot of stuff from /usr/local
starseeker (Oct 25 2020 at 17:51):Strange stuff... maybe including /usr/local isn't a good idea.
Jaidev (Oct 25 2020 at 17:52):win32 target not supported??
Jaidev (Oct 25 2020 at 17:52):is something wrong there
starseeker (Oct 25 2020 at 17:52):You've got some headers in /usr/local that are very strange.
starseeker (Oct 25 2020 at 17:52):Are you set up to cross-compile?
Jaidev (Oct 25 2020 at 17:52):no i guess
starseeker (Oct 25 2020 at 17:53):So, where did the _mingw.h header come from?
starseeker (Oct 25 2020 at 17:54):Does "dpkg -S /usr/local/include/_mingw.h" report anything?
Jaidev (Oct 25 2020 at 17:56):no path found matching pattern
starseeker (Oct 25 2020 at 17:56):So you're not sure where that came from then. OK, as a temporary measure I would suggest moving /usr/local/include to /usr/local/include.bak
starseeker (Oct 25 2020 at 17:57):Let's get those headers out of the way and see if the rest of the compile succeeds.
Jaidev (Oct 25 2020 at 17:58):how can i move to those directory
starseeker (Oct 25 2020 at 17:59):sudo mv /usr/local/include /usr/local/include.bak
Jaidev (Oct 25 2020 at 18:01):ohhh it works
Jaidev (Oct 25 2020 at 18:01):compiled
starseeker (Oct 25 2020 at 18:03):Now, does the main cmake .. process work?
Jaidev (Oct 25 2020 at 18:04):yeahh it works :blush:
Jaidev (Oct 25 2020 at 18:05):running
Jaidev (Oct 25 2020 at 18:06):Thanks @starseeker
Jaidev (Oct 25 2020 at 18:07):Build files have been written to build directory
Jaidev (Oct 25 2020 at 18:25):cmake .. -DBRLCAD_BUNDLED_LIBS=ON -DCMAKE_BUILD_TYPE=Release
* Configuring BRL-CAD Release 7.32.1, Build 20201025 *
**************
CMake Error at misc/CMake/BRLCAD_Util.cmake:96 (_message):
Installation directory (CMAKE_INSTALL_PREFIX) is set to
/usr/brlcad/dev-7.32.1, but build type is set to Release!
Call Stack (most recent call first):
CMakeLists.txt:686 (message)
-- Configuring incomplete, errors occurred!
See also "/home/jaidev/brlcad/build/CMakeFiles/CMakeOutput.log".
See also "/home/jaidev/brlcad/build/CMakeFiles/CMakeError.log".
Jaidev (Oct 25 2020 at 18:27):again for release build, there errors occured
Jaidev (Oct 25 2020 at 18:49):in cmake everything works fine
Jaidev (Oct 25 2020 at 18:49):But in make error occured
Jaidev (Oct 25 2020 at 18:49):Scanning dependencies of target cad_user
[ 17%] Building C object regress/user/CMakeFiles/cad_user.dir/cad_user.c.o
[ 17%] Linking C executable ../../bin/cad_user
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to pthread_create'
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to pthread_mutexattr_destroy'
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to pthread_mutex_trylock'
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to pthread_setaffinity_np'
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to pthread_mutexattr_init'
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to pthread_join'
/usr/bin/ld: ../../lib/libbu.so.20.0.1: undefined reference to `pthread_attr_setstacksize'
collect2: error: ld returned 1 exit status
make[2]: *** [regress/user/CMakeFiles/cad_user.dir/build.make:112: bin/cad_user] Error 1
make[1]: *** [CMakeFiles/Makefile2:57811: regress/user/CMakeFiles/cad_user.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
starseeker (Oct 25 2020 at 19:41):@Jaidev When switching from the default cmake configure to CMAKE_BUILD_TYPE=Release, did you clear your build directory? Otherwise, it will remember the previous install path (by default set to the dev path.)
starseeker (Oct 25 2020 at 19:43):In your CMakeCache.txt file, what is CMAKE_HAVE_PTHREAD_H set to?
starseeker (Oct 25 2020 at 19:46):Also, do you have libpthread-stubs0-dev installed? dpkg -l libpthread-stubs0-dev
starseeker (Oct 25 2020 at 19:49):FWIW, I was able to build on Ubuntu with the same gcc - I think that _mingw.h header may indicate you have some sort of cross-compilation setup or windows compatibility that's interfering with your compilation environment...
starseeker (Oct 25 2020 at 19:50):In this case the simplest thing, if you have the resources to do it, is to use virtualbox to set up a virtual machine, install a clean Ubuntu there, and do the compilation in the VM... otherwise you'll need to sort out your development environment.
Jaidev (Oct 26 2020 at 03:13):Does i need to build for the release build again , my default build for cmake worked fine.
Jaidev (Oct 26 2020 at 03:13):CMAKE_HAVE_PTHREAD_H:INTERNAL=1
It is set to 1 i guess.
Jaidev (Oct 26 2020 at 03:15):I have a dual boot of ubuntu 20.04 and Windows 10, i guess this is making some issue .
Jaidev (Oct 26 2020 at 03:22):$ dpkg -l libpthread-stubs0-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===========================-============-============-=====================>
ii libpthread-stubs0-dev:amd64 0.4-1 amd64 pthread stubs not pro>
lines 1-6/6 (END)
Jaidev (Oct 26 2020 at 03:23):libpthread-stubs0-dev was installed before, do i need to reinstall it
Jaidev (Oct 26 2020 at 03:25):Is there anyway without using vmbox with ubuntu, I can sort out the development environment on this.
starseeker (Oct 26 2020 at 16:05):The default build is find for getting started. If you can sort out your compilation environment that's fine, but you're getting a lot of strange errors so it may be some work to figure out - your choice.
Jaidev (Oct 26 2020 at 16:13):How can i sort the compilation environment?
Jaidev (Oct 26 2020 at 16:14):@starseeker star I am beginner in these things, not so familiar with any of the things
starseeker (Oct 26 2020 at 16:26):I don't know what specifically you need to do to fix your compilation environment - any number of things might be wrong with it.
starseeker (Oct 26 2020 at 16:27):That's why I suggested a virtual machine as an alternative.
Jaidev (Oct 26 2020 at 16:29):So, i should now shift to vmbox on windows.
Jaidev (Oct 26 2020 at 16:29):It's the only way i guess:sweat_smile::sweat_smile:
starseeker (Oct 26 2020 at 16:29):Another way is to do a clean re-install of your existing system.
starseeker (Oct 26 2020 at 16:30):I can't advise you specifically - you must decide based on what you feel comfortable doing.
Jaidev (Oct 26 2020 at 16:31):Vmbox will be better for me i guess
Jaidev (Oct 26 2020 at 16:31):Or should i install ubuntu 18.04 fresh on the current system
Sumagna Das (Oct 26 2020 at 17:30):(deleted)
Sean (Oct 26 2020 at 17:51):This should be entirely debuggable, even on a completely broken system. ESPECIALLY on a linux system. If it's not, we have a problem.
Sean (Oct 26 2020 at 17:51):It may indicate we should be more robust in our testing and reporting of assumptions being made of the system environment.
Sean (Oct 26 2020 at 17:53):@Jaidev what you'd need to do to make it helpful will be to start over, delete what you have, and keep track of every command you run and the output it gave.
Sean (Oct 26 2020 at 17:53):in particular, tell what cmake command you ran and save all output from cmake, share that log as well as the two CMakeFiles/*.log files (error and output)
Jaidev (Oct 27 2020 at 06:01):Scanning dependencies of target bu_sscanf
[ 45%] Building C object src/libbu/tests/CMakeFiles/bu_sscanf.dir/sscanf.c.o
[ 45%] Linking C executable bu_sscanf
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_mutexattr_destroy'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_create'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_mutex_trylock'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_attr_setstacksize'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_setaffinity_np'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_join'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to `pthread_mutexattr_init'
collect2: error: ld returned 1 exit status
make[2]: *** [src/libbu/tests/CMakeFiles/bu_sscanf.dir/build.make:87: src/libbu/tests/bu_sscanf] Error 1
make[1]: *** [CMakeFiles/Makefile2:21399: src/libbu/tests/CMakeFiles/bu_sscanf.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
I already had a brlcad 7.28 version , so i tried after removing it and setting the path environment
export PATH="/usr/brlcad/bin:$PATH"
export MANPATH="/usr/brlcad/man:$MANPATH"
i get the error now at 45% while compiling with make .
Jaidev (Oct 27 2020 at 06:04):Sean said:
in particular, tell what cmake command you ran and save all output from cmake, share that log as well as the two CMakeFiles/*.log files (error and output)
@Sean these are the files you asked for--
CMakeCache.txt
CMakeError.log CMakeLists.txt
CMakeOutput.log
Sean (Oct 27 2020 at 06:19):@jaidev, you didn't provide the cmake command you ran (how did you run cmake?) nor all the output from running cmake. The log files don't capture much of the output that is displayed. That said, compile next and provide that entire log. For example, assuming this is linux, you can run this: make 2>&1 | tee make.log
Sean (Oct 27 2020 at 06:24):Jaidev said:
Scanning dependencies of target bu_sscanf
[ 45%] Building C object src/libbu/tests/CMakeFiles/bu_sscanf.dir/sscanf.c.o
[ 45%] Linking C executable bu_sscanf
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference topthread_mutexattr_destroy' /usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference topthread_create'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference topthread_mutex_trylock' /usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference topthread_attr_setstacksize'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference topthread_setaffinity_np' /usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference topthread_join'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to `pthread_mutexattr_init'
collect2: error: ld returned 1 exit status
make[2]: *** [src/libbu/tests/CMakeFiles/bu_sscanf.dir/build.make:87: src/libbu/tests/bu_sscanf] Error 1
make[1]: *** [CMakeFiles/Makefile2:21399: src/libbu/tests/CMakeFiles/bu_sscanf.dir/all] Error 2
make: *** [Makefile:163: all] Error 2I already had a brlcad 7.28 version , so i tried after removing it and setting the path environment
export PATH="/usr/brlcad/bin:$PATH"
export MANPATH="/usr/brlcad/man:$MANPATH"
i get the error now at 45% while compiling with make .
It may have been finding a BRL-CAD in the install location during compile, so you can rule that out by deleting it. rm -rf /usr/brlcad
Also delete the cmake files in your build directory (rm -rf CMake*), and re-run cmake. Assuming it still errors out on pthread, run "make VERBOSE=1 2>&1 | tee make2.log" and share your make2.log file.
Sean (Oct 27 2020 at 06:37):@starseeker I think I see the issue. We no longer appear to be specifying a search for pthreads or the preference to use -pthread. There are subpackages that do, but we apparently no longer do and libbu obviously uses pthreads. Where's it supposed to be getting it from? Am I just missing it?
Sean (Oct 27 2020 at 06:48):ah, I found it .. so it's supposed to be coming from ${CMAKE_THREAD_LIBS_INIT}... so perhaps that's not getting populated correctly or BU's libs are not propagating to the bu_sscanf unit test
Sean (Oct 27 2020 at 06:49):@Jaidev, definitely would be useful to see make VERBOSE=1 on libbu and the unit test it's failing on.
Jaidev (Oct 27 2020 at 07:39):@Sean I had run the command "cmake .. " following this link https://brlcad.org/wiki/Building_from_SVN
then did exactly you asked me to do, after running "make VERBOSE=1" i got this error
[ 45%] Linking C executable bu_sscanf
cd /home/jaidev/brlcad/build/src/libbu/tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/bu_sscanf.dir/link.txt --verbose=1
/usr/bin/cc -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -pipe -fvisibility=hidden -fno-strict-aliasing -fno-common -fexceptions -m64 -g -ggdb3 -fstack-protector-all -fno-omit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Werror -m64 -g -ggdb3 CMakeFiles/bu_sscanf.dir/sscanf.c.o -o bu_sscanf -Wl,-rpath,/home/jaidev/brlcad/build/lib ../../../lib/libbu.so.20.0.1 -ldl /usr/lib/x86_64-linux-gnu/libuuid.so -lc -lm
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_mutexattr_destroy'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_create'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_mutex_trylock'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_attr_setstacksize'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_setaffinity_np'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to pthread_join'
/usr/bin/ld: ../../../lib/libbu.so.20.0.1: undefined reference to `pthread_mutexattr_init'
collect2: error: ld returned 1 exit status
make[2]: *** [src/libbu/tests/CMakeFiles/bu_sscanf.dir/build.make:87: src/libbu/tests/bu_sscanf] Error 1
make[2]: Leaving directory '/home/jaidev/brlcad/build'
make[1]: *** [CMakeFiles/Makefile2:21399: src/libbu/tests/CMakeFiles/bu_sscanf.dir/all] Error 2
make[1]: Leaving directory '/home/jaidev/brlcad/build'
make: *** [Makefile:163: all] Error 2
Jaidev (Oct 27 2020 at 07:39): starseeker (Oct 27 2020 at 12:02):find_package(Threads) CMakeLists.txt:2289 should be finding us what we need... @Jaidev what version of CMake are you using?
starseeker (Oct 27 2020 at 12:05):Looking at his CMakeError.log, line 2738 is worrisome in terms of whether or not his system is set up correctly...
Sean (Oct 27 2020 at 13:02):@starseeker the vfont test? that's a bsd interface
Sean (Oct 27 2020 at 13:03):bu_sscanf unit test's link line is missing -pthread or -lpthread, yet it's in his CMakeOutput.log it's showing as working when it's added
Sean (Oct 27 2020 at 13:42):@Jaidev we need to figure out why your thread result isn't getting added. Can you edit src/libbu/CMakeLists.txt and add a line near the top that says:
message("!!! CTLI is ${CMAKE_THREAD_LIBS_INIT}")
then re-run cmake + make, provide the output from the cmake step (ie.., "cmake .. 2>&1 | tee cmake.log")
Jaidev (Oct 27 2020 at 16:49):starseeker said:
find_package(Threads) CMakeLists.txt:2289 should be finding us what we need... Jaidev what version of CMake are you using?
I am using cmake version 3.16.3
Jaidev (Oct 27 2020 at 16:52):Sean said:
Jaidev we need to figure out why your thread result isn't getting added. Can you edit src/libbu/CMakeLists.txt and add a line near the top that says:
message("!!! CTLI is ${CMAKE_THREAD_LIBS_INIT}")
@Sean i had edited src/libbu/CMakeLists.txt
Same error occurs again
cmake.log
make2.log
Jaidev (Oct 27 2020 at 16:53):CMakeLists.txt did i make the right changes here at the top
Jaidev (Oct 27 2020 at 16:59):Does setting up my path will resolve my problem
export PATH="/usr/brlcad/bin:$PATH"
export MANPATH="/usr/brlcad/man:$MANPATH"
starseeker (Oct 28 2020 at 01:36):@Sean , @Jaidev - I switched trunk to using a newer approach to the find_package(Threads) logic - worth checking to see if it improves anything.
Sean (Oct 28 2020 at 01:37):@Jaidev okay, so that's the issue -- the variable is empty and it shouldn't be. let's see if we can figure out why it's empty.
next, edit the top-level CMakelists.txt and find the line that says find_package(Threads REQUIRED) and after it add a similar:
message("!!! CMTI in top-level is ${CMAKE_THREAD_LIBS_INIT}")
Sean (Oct 28 2020 at 01:38):do that after trying what @starseeker just suggested, just svn up and see if it prints differently during cmake
Sean (Oct 28 2020 at 01:40):rather, see if the build just works. looks like it's quite a different approach...
Sean (Oct 28 2020 at 01:41):@starseeker what is that Threads::Threads syntax?
starseeker (Oct 28 2020 at 03:02):It's an imported target - got it from reading the FindThreads.cmake file
starseeker (Oct 28 2020 at 03:03):See also https://cmake.org/cmake/help/v3.1/module/FindThreads.html
starseeker (Oct 28 2020 at 03:05):To be honest I'd be surprised if it works, but I also added logic to set the variables in the cache, so hopefully the cache file will tell us a bit more. Otherwise it involves taking apart the various steps of FindThreads.cmake.
Jaidev (Oct 28 2020 at 05:39):@Sean @starseeker I updated with svn up and changes the CMakelists.txt with adding that line after the find_package(Threads REQUIRED)
cmake and make works fine :blush:
cmake.log
make2.log
Sean (Oct 28 2020 at 05:41):That's great news @Jaidev. Now the only question is whether it was the pthread hint that fixed it or the testing method change.
Jaidev (Oct 28 2020 at 05:47):After svn up, for test i just tried cmake .. but error occurs there.
So after that i changed CMakelists.txt file...then it worked well.
Sean (Oct 28 2020 at 05:48):how did you change it?
Jaidev (Oct 28 2020 at 05:49):Simply from the text editor
Sean (Oct 28 2020 at 05:49):heh, no ... I mean what change did you make?
Jaidev (Oct 28 2020 at 05:52):@Sean #find_package(Threads REQUIRED) to find_package(Threads REQUIRED)
and after that line added this:
message("!!! CMTI in top-level is ${CMAKE_THREAD_LIBS_INIT}")
Sean (Oct 28 2020 at 05:53):o.O ... why was that find_package line commented out??
Sean (Oct 28 2020 at 05:54):that's a modification you must have made because that's not in the repository. that's why it was broken.
Jaidev (Oct 28 2020 at 05:54):Yaa, i don't know that, due to this commenting it takes me lot of time to find it, i get confused there.
Sean (Oct 28 2020 at 05:56):in the top-level source directory, run "svn diff > changes.diff"... lets make sure you don't have other edits because the two message statements.
Jaidev (Oct 28 2020 at 05:56):Ohh, i get it now than :blush:
Jaidev (Oct 28 2020 at 05:59):It is blank there.
Sean (Oct 28 2020 at 05:59):it shouldn't be blank, you made changes
Sean (Oct 28 2020 at 06:00):make sure you're in the src dir, not the build dir
Jaidev (Oct 28 2020 at 06:02):yes, at the src direcctory it's blank
Sean (Oct 28 2020 at 06:02):top-level source dir, not the "src" directory
Sean (Oct 28 2020 at 06:02):where the CMakeLists.txt is
Jaidev (Oct 28 2020 at 06:02):yes, i tried there, it is same
Jaidev (Oct 28 2020 at 06:03):blank there
Sean (Oct 28 2020 at 06:03):just run "svn diff"
Jaidev (Oct 28 2020 at 06:03):i got it
Sean (Oct 28 2020 at 06:03):what's the output?
Jaidev (Oct 28 2020 at 06:03): Jaidev (Oct 28 2020 at 06:06):@Sean when i run "make test"
1005/1005 Test #1005: regress-weight ...................................................... Passed 1.33 sec
99% tests passed, 3 tests failed out of 1005
Label Time Summary:
Benchmark = 12.05 sec*proc (1 test)
Regression = 282.22 sec*proc (118 tests)
STAND_ALONE = 72.70 sec*proc (11 tests)
Total Test time (real) = 681.06 sec
The following tests FAILED:
1 - NOTE: some 'test' tests are expected to fail, 'regress' must pass (Failed)
874 - slow-bigdb_1gb (Child killed)
875 - slow-bigdb_5gb (Failed)
Errors while running CTest
make: *** [Makefile:130: test] Error 8
Jaidev (Oct 28 2020 at 06:07):this error is showing
Sean (Oct 28 2020 at 06:08):okay, so it looks like you also commented out another line, cxx11_check_feature("lib_regex" HAS_CXX11_LIB_REGEX) ... uncomment it
Jaidev (Oct 28 2020 at 06:13):Is there any shortcut to find that line easily
Sean (Oct 28 2020 at 06:14):actually, you should be able to just run "svn revert -r" to undo all changes
Jaidev (Oct 28 2020 at 06:25):"svn revert CMakelists.txt"
Jaidev (Oct 28 2020 at 06:25):i run this command
Sean (Oct 28 2020 at 06:26):you really should speak up and say something when you encounter a problem and you're not sure what's going on
Sean (Oct 28 2020 at 06:28):that command isn't adequate -- you should have said "svn revert -r" gave you an error or read that error message and understand that I possibly gave the wrong flag. "svn help revert" would have told you the intended flag was supposed to be -R uppercase. :)
Jaidev (Oct 28 2020 at 06:29):i tried svn revert -R
Sean (Oct 28 2020 at 06:29):tried and succeeded, tried and failed, tried and not sure???
Jaidev (Oct 28 2020 at 06:30):tried and failed
Sean (Oct 28 2020 at 06:30):what was the output
Jaidev (Oct 28 2020 at 06:30):not enough arguments provided
Sean (Oct 28 2020 at 06:31):excellent
Sean (Oct 28 2020 at 06:31):same advice holds for this
Sean (Oct 28 2020 at 06:32):what does "svn help revert" tell it's expecting?
Jaidev (Oct 28 2020 at 06:33):-R [--recursive]
Jaidev (Oct 28 2020 at 06:34):i should use this
Sean (Oct 28 2020 at 06:34):no, that's a basic error message saying the command arguments are wrong
Sean (Oct 28 2020 at 06:34):something's missing
Sean (Oct 28 2020 at 06:34):hint: look at the usage line
Jaidev (Oct 28 2020 at 06:35):descend recursively, same as --depth=infinity
Sean (Oct 28 2020 at 06:35):that's not the usage for revert
Sean (Oct 28 2020 at 06:36):that's just explaining the -R option
Jaidev (Oct 28 2020 at 06:36):what should i pass on it
Sean (Oct 28 2020 at 06:37):look for the word usage...
Jaidev (Oct 28 2020 at 06:37):undo??
Sean (Oct 28 2020 at 06:37):what?
Sean (Oct 28 2020 at 06:37):no, not undo, "usage"
Jaidev (Oct 28 2020 at 06:39):svn revert --depth=infinity
Jaidev (Oct 28 2020 at 06:39):is this right
Sean (Oct 28 2020 at 06:39):no not at all
Sean (Oct 28 2020 at 06:39):I think you're fundamentally misunderstanding something
Sean (Oct 28 2020 at 06:40):do you see the output when you run "svn help revert" ?
Jaidev (Oct 28 2020 at 06:40):yess
Sean (Oct 28 2020 at 06:40):do you see a line in that output that says "usage"?
Jaidev (Oct 28 2020 at 06:40):yess that path
Jaidev (Oct 28 2020 at 06:41):revert path..
Sean (Oct 28 2020 at 06:41):correct, it wants a path
Sean (Oct 28 2020 at 06:41):svn revert -R .
Jaidev (Oct 28 2020 at 06:41):ohhh i get it
Jaidev (Oct 28 2020 at 06:42):that's the wrong thing i am doing from the beginning
Jaidev (Oct 28 2020 at 06:46):svn revert CMakelists.txt also changes the same thing
Sean (Oct 28 2020 at 06:54):it's not the same thing because that's just reverting that one file, but you edited multiple files
Sean (Oct 28 2020 at 06:54):you can always run "svn diff" to see what you've changed
Jaidev (Oct 28 2020 at 06:59):yeahh, i get those things clear now. Being a beginner it's a lot to take in at a time makes me sometimes to do the silly mistakes. :sweat_smile:
Jaidev (Oct 28 2020 at 08:18):The same errors occuring by running the command "make test"
99% tests passed, 3 tests failed out of 1005
Label Time Summary:
Benchmark = 9.97 sec*proc (1 test)
Regression = 268.92 sec*proc (118 tests)
STAND_ALONE = 48.28 sec*proc (11 tests)
Total Test time (real) = 619.83 sec
The following tests FAILED:
1 - NOTE: some 'test' tests are expected to fail, 'regress' must pass (Failed)
874 - slow-bigdb_1gb (Child killed)
875 - slow-bigdb_5gb (Failed)
Errors while running CTest
make: *** [Makefile:130: test] Error 8
Jaidev (Oct 28 2020 at 10:22):@Sean "sudo make install" worked well without any errors but the make test gave some errors there and i tried to run mged but for that i had to go to the path /usr/brlcad/bin.
How can i set the path , so that i don't have to go to that location to run mged.
i followed this link https://brlcad.org/wiki/Building_from_SVN
export PATH="/usr/brlcad/bin:$PATH"
export MANPATH="/usr/brlcad/man:$MANPATH"
But this doesn't solve anything.
Sean (Oct 28 2020 at 15:19):the bigdb failure is likely related to an error that I'm currently debugging so you can ignore it for now. I'll follow up with you to test some changes later.
Sean (Oct 28 2020 at 15:21):Jaidev said:
Sean "sudo make install" worked well without any errors but the make test gave some errors there and i tried to run mged but for that i had to go to the path /usr/brlcad/bin.
You didn't need to go to that path. You just had to either provide the full path (e.g., /usr/brlcad/bin/mged) or add it to your system PATH.
How can i set the path , so that i don't have to go to that location to run mged.
i followed this link https://brlcad.org/wiki/Building_from_SVN
export PATH="/usr/brlcad/bin:$PATH"
export MANPATH="/usr/brlcad/man:$MANPATH"
But this doesn't solve anything.
What shell do you use? Those instructions only apply to posix/bourne-style shells like bash. If you use tcsh or csh, you need different commands.
starseeker (Oct 28 2020 at 15:54):By the way, to run the tests that are known/expected to pass, you'll need to run the target "make check" rather than "make test" Due to a limitation with CMake, it's not possible to restrict the "make test" target to those tests expected to pass.
Jaidev (Oct 28 2020 at 18:07):@Sean i have bash shell and i added it to the system path with this
export PATH="/usr/brlcad/bin:$PATH"
export MANPATH="/usr/brlcad/man:$MANPATH"
but it doesn't works when i run only mged .
Jaidev (Oct 28 2020 at 18:10):@starseeker i tried running "make check" and it get successfull without any errors .
Sean (Oct 28 2020 at 19:11):@Jaidev show me a screenshot that has the output of running this:
echo $PATH
ls -la /usr/brlcad
mged
@Sean see this
Screenshot-from-2020-10-29-11-44-34.png
Sean (Oct 29 2020 at 06:22):@Jaidev okay, next you need to run "export PATH=/usr/brlcad/dev-7.32.1/bin:$PATH"
Sean (Oct 29 2020 at 06:23):then "mged" will work until you close that terminal window
Sean (Oct 29 2020 at 06:23):you can also alternatively run it directly with "/usr/brlcad/dev-7.32.1/bin/mged"
Jaidev (Oct 29 2020 at 06:24):yes, it runs .Thank you @Sean :blush:
Sean (Oct 29 2020 at 06:25):you might want to read a tutorial on how PATH works on linux if this is confusing. It's a good concept to learn.
Sean (Oct 29 2020 at 06:25):this isn't specific to BRL-CAD, it's actually not even specific to Linux
Jaidev (Oct 29 2020 at 06:26):I am reading random tutorial from the google.
Jaidev (Oct 29 2020 at 06:28):Is this a issue when i close those two windows, it gave some error bad pointer..
Vikram Atreya (Oct 29 2020 at 06:34):Jaidev said:
Is this a issue when i close those two windows, it gave some error bad pointer..
Its not specific to you, this is a to be done task
Sumagna Das (Oct 29 2020 at 06:35):Vikram Atreya said:
Jaidev said:
Is this a issue when i close those two windows, it gave some error bad pointer..
Its not specific to you, this is a to be done task
the bad pointer thing is new. its an error to be specific.
Sean (Oct 29 2020 at 06:35):bad pointer?
Jaidev (Oct 29 2020 at 06:36):ERROR: bad pointer 0x557694d2c5c0: s/b dm internal(x444d4d4d), was Zero_Magic_Number(x0), file /home/jaidev/brlcad/src/libdm/dm-generic.c, line 398
Sumagna Das (Oct 29 2020 at 06:37):Jaidev said:
ERROR: bad pointer 0x557694d2c5c0: s/b dm internal(x444d4d4d), was Zero_Magic_Number(x0), file /home/jaidev/brlcad/src/libdm/dm-generic.c, line 398
thats the error message..
Jaidev (Oct 29 2020 at 06:37):Sumagna Das said:
Jaidev said:
ERROR: bad pointer 0x557694d2c5c0: s/b dm internal(x444d4d4d), was Zero_Magic_Number(x0), file /home/jaidev/brlcad/src/libdm/dm-generic.c, line 398
thats the error message..
yess that's the error message occurs when i close both the graphical windows
Sean (Oct 29 2020 at 06:37):you mean both of mged's windows?
Jaidev (Oct 29 2020 at 06:38):yaa both
Sean (Oct 29 2020 at 06:38):ugh
Sumagna Das (Oct 29 2020 at 06:38):if you close both the windows manuallly and not by writing quit in the command window, then this dialog box pops up.
Sean (Oct 29 2020 at 06:39):well that's news to me, obviously related to the new dm code
Sean (Oct 29 2020 at 06:40):we really need to make it so that this doesn't keep happening. this feels brittle af.
Sean (Oct 29 2020 at 06:40):@Sumagna Das can you catch a backtrace?
Sumagna Das (Oct 29 2020 at 06:40):yea i can do that
Sumagna Das (Oct 29 2020 at 06:41):but let me rebuild the whole thing so that its not referring to old code.
Sean (Oct 29 2020 at 06:41):do you know how to catch that in a debugger? just run gdb mged, break on bu_exit, run, close the windows, should halt on the ERROR, bt
Sumagna Das (Oct 29 2020 at 06:41):yea
Sean (Oct 29 2020 at 06:41):b bu_bomb
Jaidev (Oct 29 2020 at 06:43):There is a task on this i guess what's it is about closing the two windows.
Sumagna Das (Oct 29 2020 at 06:43):but that is not related to this error.
Sean (Oct 29 2020 at 06:44):it's kind of related, but the Deuces task is behavior that needs to change. make the close binding just close that window, not tear down the app
Sean (Oct 29 2020 at 06:44):at least only in the sense that they both involve clicking the close window button :)
Jaidev (Oct 29 2020 at 06:46):ohhhh :sweat_smile: , i am getting new errors from the start
Jaidev (Oct 29 2020 at 06:49):Now, can i start the deuces task or have to gain some other knowledge
Vikram Atreya (Oct 29 2020 at 07:17):Jaidev said:
Now, can i start the deuces task or have to gain some other knowledge
You can start ig, I learnt things while doing it.
Jaidev (Oct 29 2020 at 07:18):I don't understand what ig is?
Vikram Atreya (Oct 29 2020 at 07:19):i guess :joy:
Sumagna Das (Oct 29 2020 at 07:19):Sean said:
do you know how to catch that in a debugger? just run gdb mged, break on bu_exit, run, close the windows, should halt on the ERROR, bt
I dont have much time right now, so i will debug it later onwards.
Jaidev (Oct 29 2020 at 07:21):Vikram Atreya said:
i guess :joy:
yes :smiley:
Sumagna Das (Oct 29 2020 at 07:22):Sean said:
do you know how to catch that in a debugger? just run gdb mged, break on bu_exit, run, close the windows, should halt on the ERROR, bt
#0 bu_bomb (str=0x7ffff7fe0187 "I\211\300d\213\004%\030") at /mnt/sda2/github/brlcad/src/libbu/bomb.c:108
#1 0x00007ffff4a8de85 in bu_badmagic (ptr=0x55555655f130, magic=1145916749, str=0x7ffff7eac937 "dm internal",
file=0x7ffff7eac908 "/mnt/sda2/github/brlcad/src/libdm/dm-generic.c", line=398) at /mnt/sda2/github/brlcad/src/libbu/badmagic.c:51
#2 0x00007ffff7e8672b in dm_get_pathname (dmp=0x55555655f130) at /mnt/sda2/github/brlcad/src/libdm/dm-generic.c:398
#3 0x0000555555579072 in release (name=0x55555659d310 ".topid_0.ll", need_close=1) at /mnt/sda2/github/brlcad/src/mged/attach.c:158
#4 0x0000555555579590 in f_release (UNUSED_clientData=0x555555678038 <mged_cmdtab+5592>, interpreter=0x5555557770f0, argc=2, argv=0x55555577b930)
at /mnt/sda2/github/brlcad/src/mged/attach.c:257
#5 0x00007ffff737c77b in TclInvokeStringCommand () from /lib/x86_64-linux-gnu/libtcl8.6.so
#6 0x00007ffff737e5f2 in TclNRRunCallbacks () from /lib/x86_64-linux-gnu/libtcl8.6.so
#7 0x00007ffff737f924 in ?? () from /lib/x86_64-linux-gnu/libtcl8.6.so
#8 0x00007ffff737f367 in Tcl_EvalEx () from /lib/x86_64-linux-gnu/libtcl8.6.so
#9 0x00007ffff72e7b78 in TkWmProtocolEventProc () from /lib/x86_64-linux-gnu/libtk8.6.so
#10 0x00007ffff721b10d in Tk_HandleEvent () from /lib/x86_64-linux-gnu/libtk8.6.so
#11 0x00007ffff721b818 in ?? () from /lib/x86_64-linux-gnu/libtk8.6.so
#12 0x00007ffff7447fc9 in Tcl_ServiceEvent () from /lib/x86_64-linux-gnu/libtcl8.6.so
#13 0x00007ffff744824d in Tcl_DoOneEvent () from /lib/x86_64-linux-gnu/libtcl8.6.so
#14 0x0000555555600be4 in event_check (non_blocking=0) at /mnt/sda2/github/brlcad/src/mged/mged.c:1978
#15 0x00005555556003bb in main (argc=1, argv=0x7fffffffd9f0) at /mnt/sda2/github/brlcad/src/mged/mged.c:1703
this is all i can give right now.
Sean (Oct 29 2020 at 07:22):excellent, that's all that was needed
Sean (Oct 29 2020 at 07:23):so release() is causing it
Sumagna Das (Oct 29 2020 at 07:23):if you need anything else, i wll give it when i come online again
Sumagna Das (Oct 29 2020 at 07:23):Sean said:
so release() is causing it
hmmm
Sean (Oct 29 2020 at 07:28):that should fix it, update and test if you would
starseeker (Oct 29 2020 at 12:53):@Sean I think I took a quick look at that - the fix you put in avoids the crash, but it looks like it's doing what it did for me and hanging the quitting process for MGED. The state management for MGED is a convoluted mess...
starseeker (Oct 29 2020 at 12:57):(gdb) thread 1
[Switching to thread 1 (Thread 0x7f5d632997c0 (LWP 3843810))]
#0 futex_wait_cancelable (private=<optimized out>, expected=0,
futex_word=0x561a63257a80) at ../sysdeps/nptl/futex-internal.h:183
183 ../sysdeps/nptl/futex-internal.h: No such file or directory.
(gdb) bt
#0 futex_wait_cancelable (private=<optimized out>, expected=0,
futex_word=0x561a63257a80) at ../sysdeps/nptl/futex-internal.h:183
#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f5d67540940,
cond=0x561a63257a58) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0x561a63257a58, mutex=0x7f5d67540940)
at pthread_cond_wait.c:638
#3 0x00007f5d674cf0af in Tcl_WaitForEvent () from /usr/lib/x86_64-linux-gnu/libtcl8.6.so
#4 0x00007f5d6748a2ce in Tcl_DoOneEvent () from /usr/lib/x86_64-linux-gnu/libtcl8.6.so
#5 0x0000561a611a1bf0 in event_check (non_blocking=0) at ../src/mged/mged.c:1975
#6 0x0000561a611a13d7 in main (argc=0, argv=0x7ffd25917bc0) at ../src/mged/mged.c:1703
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7f5d632997c0 (LWP 3843810) "mged" futex_wait_cancelable (
private=<optimized out>, expected=0, futex_word=0x561a63257a80)
at ../sysdeps/nptl/futex-internal.h:183
2 Thread 0x7f5d61007700 (LWP 3843811) "mged:disk$0" futex_wait_cancelable (
private=<optimized out>, expected=0, futex_word=0x561a63312288)
at ../sysdeps/nptl/futex-internal.h:183
3 Thread 0x7f5d60806700 (LWP 3843812) "mged:disk$1" futex_wait_cancelable (
private=<optimized out>, expected=0, futex_word=0x561a63312288)
at ../sysdeps/nptl/futex-internal.h:183
4 Thread 0x7f5d5bfff700 (LWP 3843813) "mged:disk$2" futex_wait_cancelable (
private=<optimized out>, expected=0, futex_word=0x561a63312288)
at ../sysdeps/nptl/futex-internal.h:183
5 Thread 0x7f5d5b7fe700 (LWP 3843814) "mged:disk$3" futex_wait_cancelable (
private=<optimized out>, expected=0, futex_word=0x561a63312288)
at ../sysdeps/nptl/futex-internal.h:183
6 Thread 0x7f5d5970f700 (LWP 3843815) "mged" 0x00007f5d6497912b in __GI___select (nfds=11, readfds=0x7f5d5970ecb0, writefds=0x7f5d5970ed30, exceptfds=0x7f5d5970edb0,
timeout=0x0) at ../sysdeps/unix/sysv/linux/select.c:41
(gdb)
@starseeker yes, my frustration is with the state of the code, not with your efforts. it's really easy to bugger things up when dealing with low-level I/O and mged makes it even harder with several global variables, global state, and different modes it can get into.
Sean (Oct 29 2020 at 16:06):I don't think it's avoidable without a level of cross-platform unit testing in mged that we don't currently possess.
Sean (Oct 29 2020 at 16:10):that said ... to your specific stack trace there. that's interesting. why are there 5 pthreads waiting in our main event loop... ?
I don't think we do that. This could be related to the Tcl upgrade, compiling Tcl in multithreaded mode vs single-threaded mode. Perhaps it got switched to multithreaded and there's some consequence in Tcl_DoOneEvent() that we're not handling / specifying correctly.
Sumagna Das (Oct 29 2020 at 17:58):Sean said:
that should fix it, update and test if you would
its fixed.
Sumagna Das (Oct 29 2020 at 17:59):anyone who wants to work on the "close mged when both the windows are closed" task, you can try now
starseeker (Oct 30 2020 at 03:10):@Sean In this specific case it's most likely some changes I made trying to adjust how we are managing the state tracking for multiple dms - when we fall back to just the "null" dm it seems like odd things are happening. Oddly enough the "quit" command still works, looks like... makes me wonder if closing the window couldn't just call the quit routine...
Aliasger Anees (Dec 07 2020 at 06:44):I have downloaded the source code and ran cmake.. i am having trouble compiling it..can anyone help Screenshot-276.png
Aliasger Anees (Dec 07 2020 at 06:45):Also not having a strong comp sci background..if i ask some basic questions..just tell to read on that subject more...
Aliasger Anees (Dec 07 2020 at 06:46):Aliasger Anees said:
I have downloaded the source code and ran cmake.. i am having trouble compiling it..can anyone help Screenshot-276.png
i guess some file is missing which contains mk_arb8
Aliasger Anees (Dec 07 2020 at 06:55):Aliasger Anees said:
Aliasger Anees said:
I have downloaded the source code and ran cmake.. i am having trouble compiling it..can anyone help Screenshot-276.png
i guess some file is missing which contains mk_arb8
and loads of other files.. :sweat_smile:
Sean (Dec 07 2020 at 15:12):@Aliasger Anees That error screen you posted is the right one, but we need to see the rest of the output log. The actual error is somewhere higher up in the screen. Can you save the entire log to a file and upload it here?
Sean (Dec 07 2020 at 15:13):There's loads of errors because that's how Visual Studio works by default. If some library fails with an error, it doesn't stop and you'll see additional errors for toolA, toolB, toolC etc that use that library.
Aliasger Anees (Dec 07 2020 at 18:56):@Sean I searched here and there on net but i am not able to find how to build the log file..can you help?..or suggest where to look into?
starseeker (Dec 07 2020 at 19:28):The log file isn't "built" as a separate step - it's generated by the build process
starseeker (Dec 07 2020 at 19:29):If you're wanting to capture what's happening in the terminal, the "script" command on Linux is frequently helpful for that
Aliasger Anees (Dec 08 2020 at 06:00):@starseeker i use windows 10...i am not able to find the log file..i searched my build folder(the folder where brl cad file is build...can you advice me there?
Sean (Dec 08 2020 at 09:17):@Aliasger Anees it's not a file, it's text output from Visual Studio when you tell it to build.
Sean (Dec 08 2020 at 09:17):you save that output to a file (copy-paste it)
Sean (Dec 08 2020 at 09:18):can try reading this: https://docs.microsoft.com/en-us/visualstudio/ide/how-to-view-save-and-configure-build-log-files?view=vs-2019
Aliasger Anees (Dec 08 2020 at 09:37):ok got it... :sweat_smile:
Aliasger Anees (Dec 08 2020 at 09:38):i will just give it to you in a while..
Aliasger Anees (Dec 08 2020 at 09:38):@Sean actually i was thinking of rebuilding it using cygwin and all the bash commands provided on the brl cad website
Aliasger Anees (Dec 08 2020 at 11:36): Sean (Dec 08 2020 at 15:43):cool, thanks @Aliasger Anees .. so the first error there is the important one:
Cannot open source file: 'F:\brlcad\src\libbn\sobolseq.c': No such file or directory
Sean (Dec 08 2020 at 15:44):that's a file that was renamed recently -- did you have a BRL-CAD checkout from previously that you updated? You'll need to re-run cmake for it to notice the file rename.
Aliasger Anees (Dec 08 2020 at 15:53):ok i can do that...i will just update using svn and re run cmake...and then i will let you know..
Sean (Dec 08 2020 at 16:23):may want to delete your build directory and then re-run cmake in a new one
starseeker (Dec 17 2020 at 15:21):I think I just fixed the issue where closing the MGED windows was hanging instead of exiting.
Tejaswee Sulekh (Mar 08 2024 at 08:26):@Sean I introduced myself a few days ago. I was trying to install brl-cad with appleseed enabled while following this link. I have managed to compile and install brl-cad using the instructions mentioned here but I am not able to figure out how to install appleseed. As I am using WSL for setting up the workflow and am not able to figure out how to install the dependencies for appleseed. I have added the dependencies mentioned in this document.
When I am building appleseed I end up getting warning about cmake not being able to find Boost. After a few of these error the building process ends with a error as shown below:
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Boost: Found unsuitable version "0.0.0", but required is at
least "1.61" (found /path/to/prebuilt-linux-deps/include/boost_1_61_0, )
Call Stack (most recent call first):
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:592 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.22/Modules/FindBoost.cmake:2360 (find_package_handle_standard_args)
CMakeLists.txt:248 (find_package)
As mentioned in the main "link" the second step is to install boost. But I am having trouble building and running appleseed.studio
Tejaswee Sulekh (Mar 08 2024 at 08:45):Also when I ran the command bin/mged it asked me the following:
BRL-CAD Release 7.38.1 Geometry Editor (MGED)
Thu, 07 Mar 2024 15:07:25 UTC, Compilation 0
@Diablo
attach (nu ps txt)[nu]?
Can you explain what this means. I tried going for nu and got a REPL interface instead of a graphical user interface
Sean (Mar 08 2024 at 16:53):@Tejaswee Sulekh Yes, I saw your intro - did you see my response? Not going to lie, getting Appleseed up and running from source is not simple. Now note, you CAN get the build working with an already-compiled version of Appleseed so you might want to try that instead of compiling from source. The setup is quite a bit easier. You should not need to use WSL even -- BRL-CAD's art compilation with Appleseed works compiled via Visual Studio, and it comes with all the requisite dependencies. These instructions provide a helpful walk-through: https://brlcad.org/wiki/Appleseed
Sean (Mar 08 2024 at 16:54):I can't tell you what all will need to change if you try that via WSL, but I'd imagine you'd download the Linux version of appleseed instead and first make sure that works via WSL. Then the rest should be pretty straightforward.
Tejaswee Sulekh (Mar 09 2024 at 09:33):Thanks for the input. I will try going through the walk-through for windows and get back at you. I didn't try going for a non-Appleseed enabled BRL-CAD and instead asked for help in case there was quick fix that I couldn't find. I will try to get it running on windows if it doesn't will try running them and moving forward with what you suggested in the first reply.
Mohit Halder (Mar 09 2024 at 20:49):hi, does anyone know of what to set the BRLCAD_CONFIGEXE variable to in moose cmake? I haven't been able to find myself a installation guide for moose anywhere, the other variables were self explanatory but I'm at a bind when it comes to this.
Daniel Rossberg (Mar 09 2024 at 21:26):There is a shell script brlcad-config, but not for Windows.
When you run CMake on MOOSE, you should see the message Could not find BRL-CAD root directory - please set BRLCAD_BASE_DIR in CMake. I.e., you have to create a CMake variable BRLCAD_BASE_DIR of type PATH pointing to your brlcad installation directory. In addition, on Windows, you have to set BRLCAD_VERSION. If you built brlcad from the main branch, it's 7.38.1.
Mohit Halder (Mar 13 2024 at 00:45):excuse me any idea where the rt and bu header folders are?
Mohit Halder (Mar 13 2024 at 05:28):ok sorry for the confusion, I was actually trying to set up moose and the all build project builds using the cmakelists.txt file and it doesn't have any executable thus building it doesn't actually build anything. and if I try to build the entire solution which I feel wasn't intended then I get a lot of unknown headers in directories bu and rt... Sorry if this is amuterish of me, and thanks for help
Sean (Mar 13 2024 at 06:07):@Mohit Halder they are in the top-level include/rt and include/bu folders respectively. sources are in src/librt and src/libbu
Sean (Mar 13 2024 at 06:07):all public headers are in the include dir
Sean (Mar 13 2024 at 06:08):@Mohit Halder Did you already build and install the main "brlcad" repo? You need to do that before building moose.
Sean (Mar 13 2024 at 06:09):then like Daniel said, you'll point your moose cmake at that brlcad build with the BRLCAD_BASE_DIR and BRLCAD_VERSION variables.
Mohit Halder (Mar 13 2024 at 23:50):I have generated and built the base brlcad project and I have also generated the Moose project but upon trying to build the all_build project, there come a plethora or errors mostly regarding unknown headers, this happens from what I can understand because brlcad doesn't have brlcad/build/Debug/include/brlcad as a header directory yet directly references from it
Mohit Halder (Mar 13 2024 at 23:53):as such many headers like common.h are not able to be referenced in the compiler but seems to able find them just fine if I include brlcad/common.h
Tejaswee Sulekh (Mar 18 2024 at 19:44):So, I have been trying to get "art.exe" to work on my machine. It seems like while running the CMake GUI for building brlcad.appleseed, CMake is not able to fetch Boost 1.69.0 files from the location where I have installed (unzipped) it. At first it would latch onto another instance of Boost (higher version) and use that for building the project. But this led to some issues (Mainly a few header files were missing which should've been added from appleseed directory (foundation header files)). I tried adding them manually but am not really sure as to where their location should be.
After removing the other instance of Boost and only having the required version of it. I tried building the project once more. When tried CMake wasn't able to find the files (even though I gave the location path) for boost and I kept on getting the error as follows:
Could NOT find Appleseed (missing: Appleseed_INCLUDE_DIR Appleseed_LIBRARY)
'art' appleseed ray tracing is DISABLED
Performing Test WNO_MAYBE_UNINITIALIZED_CXX_FLAG_FOUND
Performing Test WNO_MAYBE_UNINITIALIZED_CXX_FLAG_FOUND - Failed
Performing Test WNO_UNINITIALIZED_CXX_FLAG_FOUND
Performing Test WNO_UNINITIALIZED_CXX_FLAG_FOUND - Failed
CMake Warning at misc/CMake/BRLCAD_Util.cmake:90 (_message):
regress-dsp fails on some Windows platforms (pix-bw appears to hang on
github runners) - skipping
Call Stack (most recent call first):
regress/dsp/CMakeLists.txt:8 (message)
Performing Test HAVE_NO_UNUSED_BUT_SET_VARIABLE
Performing Test HAVE_NO_UNUSED_BUT_SET_VARIABLE - Failed
Performing Test HAVE_FSANITIZE_FUZZER
Performing Test HAVE_FSANITIZE_FUZZER - Success
The '-fsanitize=fuzzer' flag is supported.
CMake Warning at misc/CMake/BRLCAD_Util.cmake:90 (_message):
iges.sh doesn not currently pass on Windows - disabling
Call Stack (most recent call first):
regress/iges/CMakeLists.txt:8 (message)
CMake Warning at misc/CMake/BRLCAD_Util.cmake:90 (_message):
regress-red does not currently pass on Windows, disabling
Call Stack (most recent call first):
regress/red/CMakeLists.txt:8 (message)
-------------------- BRL-CAD Release 7.38.1, Build 20240318 --------------------
Prefix: C:/Program Files/BRL-CAD 7.38.1
Binaries: C:/Program Files/BRL-CAD 7.38.1/bin
Libraries: C:/Program Files/BRL-CAD 7.38.1/lib
Manual pages: C:/Program Files/BRL-CAD 7.38.1/share/man
Data resources: C:/Program Files/BRL-CAD 7.38.1/share
Flags common to all build configurations:
CFLAGS = /DWIN32 /D_WINDOWS -std:c11 -D_POSIX_C_SOURCE=200809L
-D_XOPEN_SOURCE=700
CXXFLAGS = /DWIN32 /D_WINDOWS /GR /EHsc -std:c++17 -D_POSIX_C_SOURCE=200809L
-D_XOPEN_SOURCE=700
LDFLAGS = /machine:x64 /STACK:10000000 /NOLOGO
Additional Compilation flags used when building with configuration Debug:
CFLAGS = /Zi /Ob0 /Od /RTC1
CXXFLAGS = /Zi /Ob0 /Od /RTC1
LDFLAGS = /debug /INCREMENTAL
Additional Compilation flags used when building with configuration Release:
CFLAGS = /O2 /Ob2 /DNDEBUG
CXXFLAGS = /O2 /Ob2 /DNDEBUG
LDFLAGS = /INCREMENTAL:NO
Compile Tcl ........................: ON
Compile Tk .........................: ON
Compile Itcl/Itk ...................: ON
Compile Iwidgets ...................: ON
Compile libpng .....................: ON
Compile libregex ...................: ON
Compile zlib .......................: ON
Compile STEPcode....................: ON
OpenGL support (optional) ..........: ON
X11 support (optional) .............: OFF
Qt support (optional) ..............: OFF
Run-time debuggability (optional) ..: ON
Build 32/64-bit release ............: 64BIT (Auto)
Build with optimization ............: Build Configuration Dependent
Build static libraries .............: ON
Build dynamic libraries ............: ON
Install example geometry models ....: ON
Generate extra docs ................: ON (html)
Elapsed configuration time: 4 minutes 45 seconds
Configuring done (295.4s)
I had an idea but I wanted to ask here before implementing it. I was thinking of adding the header files to appleseed directory manually before using CMake to build the brlcad.appleseed project while using the other instance of boost which was higher version than required (Since, CMake was able to acknowledge that).
Last updated: Jan 10 2025 at 00:48 UTC