Daniel Rossberg (Apr 30 2020 at 06:56): Daniel Rossberg (Apr 30 2020 at 06:56):I want to make sure that the brlcad.dll works with the next release (7.30.8). What's the best branch to test it? The code seems to go from trunk to RELEASE to STABLE to tags. I.e., RELEASE or STABLE would be a good candidate, or?
starseeker (Apr 30 2020 at 12:34):Right now, I'd go with RELEASE
starseeker (Apr 30 2020 at 12:35):I think I'm synced to stable, but would need to double check - you may want to wait until we decide what to do about the iges-g OSX bug report in case that requires code changes prior to release.
starseeker (Apr 30 2020 at 12:38):@Sean Quickhull.hpp is one of the files behind the bot chull command. A quick Linux test seems to work fine, but Windows is the one I'd want to check for that sort of change - IIRC it was the most work to get going originally. I'll see if I'm in a building state with trunk on Windows...
starseeker (Apr 30 2020 at 14:00):Seems to be OK on Windows.
Daniel Rossberg (Apr 30 2020 at 15:19):Okay, thanks, will test RELEASE then.
Daniel Rossberg (May 04 2020 at 15:35):Hmm, RELEASE doesn't contain the off_t for Windows fixes. I can't build the 32 bit version with Visual Studio.
Daniel Rossberg (May 04 2020 at 15:46):Another issue is the zlib in openNURBS: openNURBS-static is linked with zlib, i.e. the shared library version of it. This is not optimal for the brlcad.dll. I think, a static library shouldn't be linked with something else. This has to be done by the linker of the binary using the static library.
(I'm not sure, will test what happens.)
starseeker (May 05 2020 at 01:30):@Daniel Rossberg I did some updates to RELEASE today - do they help? (not sure yet what to do about openNURBS, but I did notice the off_t wasn't in there so I've tried to backport it.)
Daniel Rossberg (May 05 2020 at 14:08):Unfortunately, it still doesn't work. E.g., src/libbu/vls.c doesn't compile.
I could find differences in include/config_win.h.in, include/bu/glob.h, and include/bu/vls.h which could be of relevance, but replacing them didn't fixed it. I wasn't able to find the difference between revision 75083b(my reference) which breaks the build yet.
BTW, don't take care of the "zlib in openNURBS" thing. I can easily fix it for my purpose, and if it works I can regularly commit it to the trunk.
starseeker (May 05 2020 at 16:18):@Daniel Rossberg I think I may have had to start from a clean build directory.
starseeker (May 05 2020 at 16:19):@Daniel Rossberg are you working with RELEASE or trunk?
starseeker (May 05 2020 at 16:19):RELEASE is the one I thought I got working yesterday with the off_t updates...
Daniel Rossberg (May 05 2020 at 16:49):Daniel Rossberg are you working with RELEASE or trunk?
I did the tests with RELEASE, but compared them with a revision from the trunk where I know it works.
Daniel Rossberg (May 05 2020 at 16:52):Daniel Rossberg I think I may have had to start from a clean build directory.
From which revision did you forked the RELEASE? The last one before the TCL upgrades?
Maybe, you can choose a revision from the trunk for the fork, and I test this revision in advance if it works for me.
starseeker (May 05 2020 at 17:44):RELEASE was forked a long time back - we periodically merge from trunk. The last big merge was well before the Tcl upgrade.
starseeker (May 05 2020 at 17:46):Can you tell me what build error you were seeing with a vanilla RELEASE checkout that's current as of this morning? Most likely culprit is something to do with the regex.h header...
starseeker (May 05 2020 at 19:24):@Daniel Rossberg I think I got past the libbu issue - let me know if that does it for you
Daniel Rossberg (May 06 2020 at 08:58):RELEASE compiles now with VS2019, both 32 and 64 bit.
starseeker (May 06 2020 at 13:01):Excellent, thanks! Everything look like it is working OK?
Daniel Rossberg (May 06 2020 at 13:06):Until now: Yes.
I haven't done much tests yet, but the BrlCadViewer seems to work, at least.
starseeker (May 06 2020 at 13:07):Sounds good.
Daniel Rossberg (May 06 2020 at 13:09):Thanks! :)
starseeker (May 06 2020 at 13:14):np - thank you for catching it before we released! trunk is still shaking down from a lot of changes, so I'd like 7.30.8 to be working as widely as possible while we work through the updates.
Daniel Rossberg (May 06 2020 at 15:24):This time I want to build a new brlcad.dll from the release. We found some bugs in the old one (from 2016?) and I would like to have an official new one.
starseeker (May 06 2020 at 15:44):very good - let me know if you have any trouble getting the dll to build from RELEASE branch. I'm not ready to tag yet anyway, so there's still time to address any issues.
Sean (Aug 05 2025 at 04:10):For awareness, we're working on release testing for our next 7.42.0 release now. This is a pretty big one with the new BoT ray tracing speed enhancements and support for concave arb8. As such, big or risky commits should be kept to a minimum or put in branches until after release is tagged. Anything big and we have to restart cross platform and integration testing.
That said, if anyone is able and willing -- this release could use some additional hands-on testing. Please report any anomalies, bombs, crashers, etc, especially anything in mged, rt* tools, gqa, any raytrace behaviors on bot or arbs, etc. Even better if you can help fix anything you find, but the testing is worthwhile regardless. I've found a fixed a number over the past few days just doing basic actions, so every little bit will help.
Sean (Aug 11 2025 at 18:24):Far as I know, we're just about ready to release -- does anyone have any release blockers to put forward or has anyone encountered any unexpected failures?
Daniel Rossberg (Aug 13 2025 at 09:27):MS Visual Studio complains about the _Thread_local in src/librt/primitives/bot/bot.c. thread_local doesn't work either, even if it's contained in the documentation. But, __declspec(thread) does.
In addition, fuzz_shootray_test and fuzz_ged_test cannot be build. There is no /fsanitze=fuzzer linker option.
However, I can live with these issues and hope to get the current compiler version soon.
Daniel Rossberg (Aug 14 2025 at 09:25):BTW, I was successful in compiling a MOOSE based brlcad.dll with only OS-dependencies, i.e. static C runtime linking. Its size is only 6.5 MB. Maybe, I'll prepare a release based on version 7.42.0.
starseeker (Aug 14 2025 at 11:20):@Daniel Rossberg Which version of Visual Studio are you building with?
starseeker (Aug 14 2025 at 11:21):We didn't see any issues with _Thread_local in our testing, which included Visual Studio 2022, so I'm a little curious.
Daniel Rossberg (Aug 14 2025 at 11:25):I'm using Visual Studio 16 (2019). Some of the more modern features (which may include C++11) may be not be supported by it.
starseeker (Aug 14 2025 at 11:25):If you add this right before the _Thread_local usage, does it work?
#if defined(HAVE_WINDOWS_H) && !defined(_Thread_local)
# define _Thread_local __declspec(thread)
#endif
Ah, yeah - that would explain it. I'm more surprised the fuzzer tests tried to build at all - our tests for the compiler options must need tweaking.
Daniel Rossberg (Aug 14 2025 at 12:21):starseeker said:
If you add this right before the _Thread_local usage, does it work?
#if defined(HAVE_WINDOWS_H) && !defined(_Thread_local) # define _Thread_local __declspec(thread) #endif
It works for MSVC 2019.
starseeker (Aug 14 2025 at 17:13):@Sean Would it be worth a block in common.h to ensure _Thread_local is always defined?
Sean (Aug 15 2025 at 16:32):@starseeker that can't hurt. We don't need to bend over backwards for 2019, but if it's still just a couple minor easy things like that, certainly worth it.
Sean (Aug 15 2025 at 16:34):I've noticed the fuzzer issue -- that's been an issue in the windows warning logs for a couple years. the test for the fuzzer flag passes despite it not working. it emits an annoying warning.
Sean (Aug 15 2025 at 16:34):I tried to quell/fix it a while back but cmake was fighting me on it.
Sean (Aug 15 2025 at 16:39):Sean said:
For awareness, we're working on release testing for our next 7.42.0 release now. This is a pretty big one with the new BoT ray tracing speed enhancements and support for concave arb8. As such, big or risky commits should be kept to a minimum or put in branches until after release is tagged. Anything big and we have to restart cross platform and integration testing.
...
For anyone not paying attention, release 7.42.0 was posted (thanks to @starseeker) earlier this week. On to the next one!
starseeker (Aug 16 2025 at 02:40):@Sean So I don't get yelled at again - is this overkill?
/* Make sure _Thread_local is defined. Note that if __declspec(thread) or
* __thread are used, they will only work for "plain old data" types
* with trivial constructors/destructors. */
# if !defined(_Thread_local)
# if defined(__cplusplus)
# if __cplusplus >= 201103L // C++11 has thread_local keyword
# define _Thread_local thread_local
# elif defined(HAVE_WINDOWS_H)
# define _Thread_local __declspec(thread)
# elif defined(__GNUC__) || defined(__clang__)
# define _Thread_local __thread
# endif
# else
# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L
# define _Thread_local thread_local // C23: thread_local is the standard keyword
# elif defined(HAVE_WINDOWS_H)
# define _Thread_local __declspec(thread)
# elif defined(__GNUC__) || defined(__clang__)
# define _Thread_local __thread
# endif
# endif
# endif
I'm sorry @starseeker I didn't mean anything to come across as yelling, just code health / maintenance commentary.
Assuming it works, I think the code block you have there looks good!
For the comment, I'd suggest tightening that up to not explain C/C++, but rather the implication. It's a platform toggle so __declspec() and __thread ARE used, not "if"... Maybe:
/* make sure we have local threading, only to be used on C "POD" types */
Sean (Aug 16 2025 at 05:04):Might be good to introduce a THREADLOCAL and use that (similar to EXTERNVARINT, NORETURN, etc) given _Thread_local is actually deprecated... (it's thread_local to sync with C++)
starseeker (Aug 16 2025 at 12:55):THREADLOCAL sounds good - is "POD" common enough shorthand that we can assume it is universally understood? Just for myself, I had to ask GPT to clarify what it stood for - it's new to me.
starseeker (Aug 17 2025 at 02:49):If we go with THREADLOCAL, I think it boils down to this?
/* Make sure THREADLOCAL is defined, only usable on C "POD" types */
#ifndef THREADLOCAL
# if defined(__cplusplus) && __cplusplus >= 201103L
# define THREADLOCAL thread_local // C++11: thread_local is standard
# elif !defined(__cplusplus) && defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L
# define THREADLOCAL thread_local // C23: thread_local is standard
# elif !defined(__cplusplus) && defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
# define THREADLOCAL _Thread_local // C11: _Thread_local is standard
# elif defined(HAVE_WINDOWS_H)
# define THREADLOCAL __declspec(thread)
# elif defined(__GNUC__) || defined(__clang__)
# define THREADLOCAL __thread
# endif
#endif
starseeker said:
THREADLOCAL sounds good - is "POD" common enough shorthand that we can assume it is universally understood? Just for myself, I had to ask GPT to clarify what it stood for - it's new to me.
Stroustrup's book "The C++ Programming Language" is worth reading if you haven't yet. POD was a concept it coined way back in the 90's, and it's mentioned in many other books since.
Sean (Aug 17 2025 at 03:57):I believe the c++98 standard referenced it directly as well, and c++11 formalized/clarified a change to it's meaning -- essentially compatibility with C types.
Sean (Aug 17 2025 at 04:03):block looks good to me at a glance. would be worth adding a #else with #error (or #define it to thread_local as the fallback) just so we don't accidentally fall through with THREADLOCAL undefined and we end up with global vars and threading issues.
Nathan McCorkle (Aug 17 2025 at 22:20):does anyone have a windows build with qged ?
starseeker (Aug 19 2025 at 00:37):I suppose I could make one, but I've not checked qged in a while - other priorities - so it may or may not behave itself. I do know at least one of the view control panels needs to be reworked.
starseeker (Aug 19 2025 at 02:51):https://brlcad.org/~starseeker/BRL-CAD_7.42.0_win64_experimental_Qt.exe
Last updated: Sep 17 2025 at 00:50 UTC