You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I cloned the repo and ran make test with no options. The output of this command is attached. As you can see, tests is compiled and linked successfully, but then fails at runtime. The exact same sequence of actions on another machine works with no issues. Running make test USE_PCRE=false works with no issues.
One suspicious thing I've noticed is that running ldd build.gnu.debug/tests produces the following output
i.e. libpcre and libpcreposix are not marked as needed even though they are linked. Check out my question here if you want to know more about this. -Wl,--no-as-needed can be used to force linker to link libpcreposix and libpcre, but that does not fix the issue. The fact that without this option the libraries do not show up in the output of ldd may mean that the program still calls the default implementation from <regex.h> at runtime, which causes the issue because the constants in configure_ftlRegex.inc are generated for PCRE.
The text was updated successfully, but these errors were encountered:
Well, like I mentioned in the original post, it works with no issues on another machine for me as well. This might be machine-dependent. I use gcc 9.3.0 and ubuntu 20.04.
I cloned the repo and ran
make test
with no options. The output of this command is attached. As you can see,tests
is compiled and linked successfully, but then fails at runtime. The exact same sequence of actions on another machine works with no issues. Runningmake test USE_PCRE=false
works with no issues.One suspicious thing I've noticed is that running
ldd build.gnu.debug/tests
produces the following outputi.e.
libpcre
andlibpcreposix
are not marked as needed even though they are linked. Check out my question here if you want to know more about this.-Wl,--no-as-needed
can be used to force linker to linklibpcreposix
andlibpcre
, but that does not fix the issue. The fact that without this option the libraries do not show up in the output ofldd
may mean that the program still calls the default implementation from<regex.h>
at runtime, which causes the issue because the constants inconfigure_ftlRegex.inc
are generated forPCRE
.The text was updated successfully, but these errors were encountered: