-
-
Notifications
You must be signed in to change notification settings - Fork 69
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
5.264.0: linking fails on missing GetDefaultResources
symbol
#165
Comments
This is the library that this symbol should be defined in.. |
Hmm .. [tkloczko@pers-jacek glsl]$ objdump -x /usr/lib64/libglslang-default-resource-limits.a | grep GetDefaultResources
25 .gnu.lto__Z19GetDefaultResourcesv.513.ebda98ceefa8c670 00000122 0000000000000000 0000000000000000 00006c54 2**0 |
Just in case I'm using glslang 1.3.239.0. |
Try setting |
Seems to be the same issue, possibly - I think your build of |
I'm building with LTO everytjong by building with set of env variables and you can see in LTO options in linkiging command [tkloczko@pers-jacek SPECS]$ rpm -E %set_build_flags
ASMFLAGS="-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none";
CFLAGS="-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none";
CXXFLAGS="-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none";
FFLAGS="-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules";
FCFLAGS="-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules";
LDFLAGS="-Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,--build-id=sha1";
VALAFLAGS="${VALAFLAGS:--g}" ; export VALAFLAGS ;
CC="/usr/bin/gcc"; CXX="/usr/bin/g++"; FC="/usr/bin/gfortran";
AR="/usr/bin/gcc-ar"; NM="/usr/bin/gcc-nm"; RANLIB="/usr/bin/gcc-ranlib";
export ASMFLAGS CFLAGS CXXFLAGS FFLAGS FCFLAGS LDFLAGS VALAFLAGS CC CXX FC AR NM RANLIB; |
Ah, I see. Then it might even be a GCC bug? Maybe you can try using a dynamically linked build of glslang instead? |
Don't worry about it, works as expected. Due to meson limitation (mesonbuild/meson#8232) with libraries that has only cmake configuration, we manually search those libraries and to support GCC LTO objects have very limited compatibility so you should always use From quick look at the commands you posted I don't see anything wrong. If both are build with the same compiler version, it should be fine. I might try to repro tomorrow, but I really doubt there is an issue on libplacebo side. Could you try this minimal case, to see if it works for you? #include <glslang/Public/ResourceLimits.h>
int main() {
const TBuiltInResource *res = GetDefaultResources();
return res->maxLights;
} |
OK I made that test [tkloczko@pers-jacek SPECS]$ g++ t.cc -lglslang-default-resource-limits
/usr/bin/ld: /tmp/ccncLepp.o: in function `main':
t.cc:(.text+0x9): undefined reference to `GetDefaultResources()'
collect2: error: ld returned 1 exit status After rebuild glslang with [tkloczko@pers-jacek SPECS]$ g++ t.cc -lglslang-default-resource-limits
/usr/bin/ld: /tmp/ccE1rSpu.ltrans0.ltrans.o:(.debug_info+0x2f): undefined reference to `ResourceLimits.cpp.31915807'
/usr/bin/ld: /tmp/ccE1rSpu.ltrans0.ltrans.o:(.debug_info+0x46): undefined reference to `ResourceLimits.cpp.31915807'
collect2: error: ld returned 1 exit status Hmm .. so what I ssuppose to do in that situation? 🤔 |
IS this still an issue? |
It works if you do |
Adding library to link with to C++ compile option looks like deeper problem in meson files.
|
Something is wromg and I cannot figure out what exactly
In meson output are contradicting lines
The text was updated successfully, but these errors were encountered: