On 26/08/2019 11:34, Alex Peshkoff via Firebird-devel wrote: > On 22.08.2019 19:22, Adriano dos Santos Fernandes wrote: >> On 22/08/2019 06:20, peshkoff--- via Firebird-devel wrote: >>> Before making a choice i want to know why only optimized build is >>> affected. Pay attention - delete is redefined in it too. Why that >>> behavior difference? >>> >>> >> Alex, my understand is that non-optimized code calls the classes >> (std::string, etc) methods/constructor/destructor all from libstdc++.o, >> as they are not inlined, but optimized code inlines only the destructor. >> The same thing happens with both g++ and clang++. > > OK, that makes sense, though something strange remains - when > libstdc++.so is compiled IMHO rather high optimization level is used. > In that case such destructors are treated as inlineable and should not > be included into shared library.
I think non-private-cpp code is always exported, even when inlined. > But it's invoked by non-optimized code! I.e. in case of optimized code > we have 2 copies of dtor - in libstdc++.so and inlined. Is it ok that > 2 copies of same code exist? At the first glance that looks like very > suspicious (not to say more) interface to libstdc++. In a case when > dtor code is changed (for example due to use of new libstdc++ version) > inlined code will run anyway and I do not see a reliable way to avoid > crashes in such case. > More below. > But leaving that problems not directly touching us rignt now - what > version of new/delete (std or our) is used by std:: objects when > linked with -static-libstdc++? Should be our, just want to make sure. Our. I think it's safe that duplicated code in our .o/.a will replace system ones. > > And last question. I do not accept an argument for not using re2 as > shared library. Sorry but "since re2 is C++ library" does not seem to > be related with linking it static or shared. We have so lot c++ shared > libraries - starting with fbclient ;). I do not want to say that use > of -static-libstdc++ is bad solution, just want to make sure in common > understanding why it should be used. As for me I see nothing bad with > use of shared re2 too. For example decfloat modules are linked static > cause API it's API has alot of macros, tomcrypt has size of external > objects dependent upon macros defined or not when building it in that > way making use of system library dangerous. You noted situation above and I could give more reasons: - re2 has it interface in C++, i.e., there is not C wrapper function receiving C objects like ICU, so when we use shared re2, we'll using libstdc++ in our code, and it could be inlined there to, and used together with the shared one - We have compatibility problems with libstdc++. AFAIK current official binaries does not work with recent Ubuntu versions. - You said many times plan to not deliver official binaries anymore. I think it's wrong approach. Many places are deploying Linux binaries and binaries that just works in whatever distro. Most of times they are compiled with GO and just statically linked. If we link static libstdc++, we will go in that direction of more compatible binaries. - C++ is becoming very great and we are too limited with our own libraries. > What is the reason for re2? > Fix many infinite evaluation (due to exponential complexity) of SIMILAR TO / SUBSTRING...SIMILAR. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
