***Emulatorman_ is now known as Emulatorman
***Server sets mode: +nt
<youpi>nm -D libm.so.6 | grep expf_ <youpi>0000000000042fd0 i __expf_finite <youpi>nm -D libm.so.6 | grep -e '\<expf\>' <youpi>that means that libm *does* provide the symbol <youpi>really , start with such a report <youpi>since that's an actual case people can have a look at and check what happened <youpi>(glibc even has a checklist to make sure that such compatibility symbols don't disappear) <damo22>i wanted to report that, but i forgot where it was i just found it now <damo22>is that supposed to be backward compatible <youpi>.so files are linked binaries <damo22>but it looks like they didnt work <youpi>well they then need to provide the actual files to show how they exactly look like <youpi>with objdmup etc. to make sure what actually happens <youpi>because really glibc is terribly careful about this kind of situation ***dingenskirchen1 is now known as dingenskirchen
<damo22>youpi: i think the .so was not linked with -lm <damo22>so it didnt get the symbol versioning <youpi>that's what aurel reported indeed <youpi>and indeed, not linking against a library means not getting proper compatibility <youpi>since compatibility relies on symbol versioning <damo22>i checked the source it is missing -lm <damo22>youre right i would have saved typing and fuss if i just reported the use case that demonstrated a failure <damo22>youpi: fweimer came to #ardour to discuss the issue, TLDR; <fweimer> No problem. For the record, I think you should drop -fno-finite-math-only again (if you are happy with -ffast-math—not everyone is) and link with -lm instead. <youpi>Posterdati: no, just ran startx wmaker ***slyfox_ is now known as slyfox