starseeker (Feb 15 2022 at 20:03): starseeker (Feb 15 2022 at 20:03):Observation on the ged_exec changes - going that route, we're basically down to runtime-only detection of any errors in programmatic usage of libged. I was originally hesitant to go ged_exec only, on the theory that at least with ged_zap et. al. being explicitly called out we would have a modicum of validation that the code was calling something that is intended to be present in libged. I'm not opposed to going with the simpler route, but I just want to make sure and call out that we are moving to a runtime-only-validation configuration. I know we already had that anyway with GED argc/argv argument processing, so in one sense it's not a huge change, but since it does lose us that "compiler checking the command name is valid" insight I wanted to mention it.
Sean (Feb 15 2022 at 20:21):I think with everything being dynamically loaded, it really makes the most sense. Otherwise, it's already really a dynamic call and the only saving grace is that we had to violate modularity to expose it.
Sean (Feb 15 2022 at 20:21):They're technically already dynamic in a sense because of the automatic wrapper calling into ged_exec(), the only difference being the wrapper serving as a potential debugger breakpoint, but the actual call was still subject to whatever was put into argv[0]. architecturally the work was still happening dynamically.
Sean (Feb 15 2022 at 20:25):I think the big win is modularity. Having every plugin have to be defined inside libged really defeats having everything in one place and propagates solutions like the mged/setup.c and tclcad/commands.c listings when they can/should just call exec.
Plus the plugins themselves can still define a public ged_cmd function now if they want, and that will work. They can be prebound into one library or linked against individually.
Daniel Rossberg (Apr 16 2026 at 15:41):How is the new libged plugin method supposed to work? I get a lot of errors like
/bin/ld: libbrlcad.so: undefined reference to `__ged_cmd_ptr_fbclear_cmd'
when linking statically to libged.a.
Sean (Apr 18 2026 at 14:48):Hopefully @starseeker can chime in because I'm having trouble making sense of the plugin.h interface. way too many layers of complexity and preprocessor hell imho.
it looks like the REGISTER_GED_COMMAND() macro is ultimately what is creating that symbol (a struct pointer). I just don't see where that is coming from.
GED_DECLARE_COMMAND_SET -> GED_DECLARE_COMMAND_METADATA -> LIST_MACRO -> GED__DECL_META_X -> .. appears to result in the former struct ged_cmd_impl declaration, so that's not it.
Sean (Apr 18 2026 at 14:51):there appears to be three different preprocessor symbols that control visibility, LIBGED_STATIC_CORE and GED_PLUGIN_ONLY and GED_PLUGIN so presumably something is mismatched there.
Sean (Apr 18 2026 at 14:59):Looks like LIBGED_STATIC_CORE is on by default, so it's declaring those entry points but then somehow they're not actually available. Quick guess would be to try setting -DLIBGED_STATIC_CORE=OFF when building BRL-CAD might be a workaround but presumably something needs to be fixed declaration-wise for the static lib to be right (if it's referencing __ged_cmd_ptr_*'s that don't exist in the .a, that's a mistake). If you nm -a libged.a, do you see __ged_cmd_ptr_fbclear_cmd ?
Daniel Rossberg (Apr 18 2026 at 15:50):The static libged.a has round about have the size of the dynamic libged.so. Usually, the static libraries are larger than the dynamic ones. E.g., librt.a has more than 3 times the size of librt.so. (I've Debug build.) Therefore, there seems to be something missing.
nm -a libged.a | grep fbclear
U __ged_cmd_ptr_fbclear_cmd
0000000000007568 T ged_exec_fbclear
0000000000000648 d _ZZ16ged_exec_fbclearE7cmdname
Looks like a mistake in src/libged/CMakeLists.txt - I was only doing the plugin sources and build flags propagation for libged, not libged-static. https://github.com/BRL-CAD/brlcad/commit/728627f981a109ae1c07869a45c2c1ff81cea07c results in a jump in libged.a size locally for me from 17M to 81M
starseeker (Apr 19 2026 at 02:20):@Daniel Rossberg Is misc/win32-msvc still fairly representative of how you're assembling your libbrlcad.so file? I really need to get something into our main build that tickles the files the way your setup does so we see breakages like this one immediately...
Daniel Rossberg (Apr 19 2026 at 17:56):starseeker said:
Daniel Rossberg Is misc/win32-msvc still fairly representative of how you're assembling your libbrlcad.so file? I really need to get something into our main build that tickles the files the way your setup does so we see breakages like this one immediately...
To be honest, I haven't used this since years. MOOSE is the way to go. It would be okay for me to remove this.
Last updated: Apr 21 2026 at 01:28 UTC