Skip to content

Conversation

@anderkve
Copy link
Collaborator

As discussed in PR #359:

The typedefs that used to go into the frontend header are now written to a separate file backend_types/typedefs.hpp. This is included in the frontend header and in backend_types/loaded_types.hpp.

@anderkve anderkve requested a review from tegonzalo August 30, 2022 11:53
@anderkve
Copy link
Collaborator Author

I'll perform some tests to see how this affects ditching the BOSSed backends. Update to follow.

@anderkve
Copy link
Collaborator Author

OK, test results are in. Just moving the typedefs out of the frontend header isn't enough to completely solve the issue of ditching BOSSed backends -- we can still have an issue with the factory functions defined via the LOAD_LIBRARY macro. (See gm2calc test results below.) But moving the typedefs to a separate header is anyway a step in the right direction (seems to do the trick for Vevacious), and anyway worth doing just for code clarity.

I've tested with the branches BOSS_typedef_header (this) and master, ditching either gm2calc or vevacious, and always starting from a completely fresh repo clone. Results:

First tests where I ditch gm2calc:

  • Branch: master
  • -Ditch="gm2calc"
  • GAMBIT compiles OK, but fails with linking error pointing to a undefined reference for a gm2calc factory function.
[100%] Linking CXX executable ../gambit
/usr/bin/ld: PrecisionBit/CMakeFiles/PrecisionBit.dir/src/PrecisionBit.cpp.o: in function `gm2calc_1_3_0::gm2calc::MSSMNoFV_onshell::MSSMNoFV_onshell()':
PrecisionBit.cpp:(.text._ZN13gm2calc_1_3_07gm2calc16MSSMNoFV_onshellC2Ev[_ZN13gm2calc_1_3_07gm2calc16MSSMNoFV_onshellC5Ev]+0x18): undefined reference to `gm2calc_1_3_0::gm2calc::MSSMNoFV_onshell::__factory0'
collect2: error: ld returned 1 exit status

We get exactly the same issue on the new branch:

  • Branch: BOSS_typedef_header
  • -Ditch="gm2calc"
  • GAMBIT compiles OK, but fails with linking error pointing to a undefined reference for a gm2calc factory function.
[100%] Linking CXX executable ../gambit
/usr/bin/ld: PrecisionBit/CMakeFiles/PrecisionBit.dir/src/PrecisionBit.cpp.o: in function `gm2calc_1_3_0::gm2calc::MSSMNoFV_onshell::MSSMNoFV_onshell()':
PrecisionBit.cpp:(.text._ZN13gm2calc_1_3_07gm2calc16MSSMNoFV_onshellC2Ev[_ZN13gm2calc_1_3_07gm2calc16MSSMNoFV_onshellC5Ev]+0x18): undefined reference to `gm2calc_1_3_0::gm2calc::MSSMNoFV_onshell::__factory0'
collect2: error: ld returned 1 exit status

Then tests with ditching Vevacious:

  • Branch: master
  • -Ditch="Vevacious"
  • GAMBIT compiles and links OK
  • Segfaults when trying to run ./gambit backends

But on the new branch this now seems to work:

  • Branch: BOSS_typedef_header
  • -Ditch="Vevacious"
  • GAMBIT compiles and links OK
  • ./gambit backends runs OK and lists Vevacious as absent/broken

It's not clear to me why we only get the factory linking issue for gm2calc and not Vevacious --- presumably it's about differences in how gm2calc and Vevacious are being used in GAMBIT, or about the fact that we define some BE_FUNCTIONs for gm2calc...

My suggestion would anyway be that we merge this simple PR as an independent BOSS improvement, and then take the deeper discussion of how to ditch BOSSed backends back in #359. Or perhaps even start a new issue with gm2calc as our test case.

What do you think, @tegonzalo? (Happy to keep working on the issue here if you prefer.)

@tegonzalo
Copy link
Collaborator

This is off the top of my head, so it could be wrong. When you ditch a backend, then the type harvester ignores it's frontend when collecting types. That is why you end up with undefined references. I honestly don't know what's up with vevacious, it's always given me an undefined reference error, never segfault. In any case, if my suspicion is correct, you should still get the same error in your branch without ditching the backends, because now you've moved the types to another file that the harvester doesn't know. My recommendation is that you just add the typedefs files to the list of searchable files for the harvester. These will always be there even if the backend is ditched, so the harvester will find them always.

…d backend and includes it in backend_types_rollcall.hpp

	modified:   Backends/scripts/backend_harvester.py
	modified:   Utils/scripts/harvesting_tools.py
@anderkve
Copy link
Collaborator Author

Finally had another look at this. I've updated the backend harvester script to harvest the new typedefs.hpp file that is now generated for each BOSSed backend, so it includes it in backend_types_rollcall.hpp below the list of the loaded_types.hpp files.

I think this is anyway sensible, but it doesn't solve the undefined reference problem for factory functions of ditched backends, like the case for gm2calc above. The reason is the same as before: the factory function is defined by the LOAD_LIBRARY macro in the frontend header, so when the frontend header is ditched, the factory functions will be undefined, independent of where we place typedefs for the BOSSed classes.

So perhaps we should just now finally ditch backend ditching and say that all frontend headers always will be compiled? We can discuss it in the Core meeting tomorrow.

@anderkve
Copy link
Collaborator Author

anderkve commented Nov 23, 2022

Quick update after our discussion today: A first test of extracting the handover_factory_pointer code + related necessary code from the LOAD_LIBRARY macro expansion and placing it in a cpp file seems to fix the undefined reference error.

But currently I'm just getting some fatal exception: map::at error when I try to run any gambit command. So I'll need to track that down before we can conclude that this might actually work.

A funfact I learned today: Even when ditching all modules except ExampleBit_*, the fully expanded code for gambit.cpp is around 450k lines... :D

@anderkve anderkve added the WIP work in progress label Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

WIP work in progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants