Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registration may not run when using the C++ interface #2424

Open
aDifferentJT opened this issue Jul 12, 2023 · 4 comments
Open

Registration may not run when using the C++ interface #2424

aDifferentJT opened this issue Jul 12, 2023 · 4 comments
Labels

Comments

@aDifferentJT
Copy link

The C++ standard says that:

If no variable or function is odr-used from a given translation unit, the non-local variables defined in that translation unit may never be initialized (this models the behavior of an on-demand dynamic library). However, as long as anything from a translation unit is odr-used, all non-local variables whose initialization or destruction has side effects will be initialized even if they are not used in the program.

https://en.cppreference.com/w/cpp/language/initialization#Deferred_dynamic_initialization

Since the generated C++ files do not contain any variable or function that is odr-used this means that the compiler is free not to initialise the factory instance and so that factory doesn't get registered and souffle::ProgramFactory::newInstance fails to find the program.

@quentin
Copy link
Member

quentin commented Jul 25, 2023

Hi, do you have a working example that exhibits such issue? Any platform or compiler where newInstance fails to find the program?

@aDifferentJT
Copy link
Author

Indeed, I ran into this issue when linking the generated C++ file with a Rust program. At first I thought it was a Rust issue but they pointed out that this behaviour is allowed by the C++ standard.

@quentin
Copy link
Member

quentin commented Jul 29, 2023

Can you reproduce with a 100% C++ test? Would you like to suggest a fix?

@aDifferentJT
Copy link
Author

I am not aware of a C++ compiler whose default linker behaves this way, nor is there an easy fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants