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?
Right now, I'd go with RELEASE
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.
@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...
Seems to be OK on Windows.
Okay, thanks, will test RELEASE then.
Hmm, RELEASE doesn't contain the off_t for Windows fixes. I can't build the 32 bit version with Visual Studio.
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.)
@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.)
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.
@Daniel Rossberg I think I may have had to start from a clean build directory.
@Daniel Rossberg are you working with RELEASE or trunk?
RELEASE is the one I thought I got working yesterday with the off_t updates...
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 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.
RELEASE was forked a long time back - we periodically merge from trunk. The last big merge was well before the Tcl upgrade.
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...
@Daniel Rossberg I think I got past the libbu issue - let me know if that does it for you
RELEASE compiles now with VS2019, both 32 and 64 bit.
Excellent, thanks! Everything look like it is working OK?
Until now: Yes.
I haven't done much tests yet, but the BrlCadViewer seems to work, at least.
Sounds good.
Thanks! :)
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.
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.
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.
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.
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?
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.
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.
@Daniel Rossberg Which version of Visual Studio are you building with?
We didn't see any issues with _Thread_local in our testing, which included Visual Studio 2022, so I'm a little curious.
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.
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.
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.
@Sean Would it be worth a block in common.h to ensure _Thread_local is always defined?
@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.
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.
I tried to quell/fix it a while back but cmake was fighting me on it.
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!
@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 */
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++)
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.
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.
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.
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.
does anyone have a windows build with qged ?
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.
https://brlcad.org/~starseeker/BRL-CAD_7.42.0_win64_experimental_Qt.exe
Last updated: Sep 13 2025 at 00:46 UTC