Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
What did your debugger say? Was the segfault caused by dereferencing a pointer returned by a failed dynamic_cast? To my knowledge flto has never been working perfectly since g++ 4.8 on Windows: multiple definitions, undefined references, pointer-to-function referring garbage memory, valid pointers becoming null, random segment faults, etc... I strongly suggest you not use flto in production builds. -- Best regards, lh_mouse 2015-05-29 - 发件人：Etienne Sandré-Chardonnal etienne.san...@m4x.org 发送日期：2015-05-29 00:33 收件人：mingw-w64-public 抄送： 主题：Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1 Hi, This worked, the program compiles fine now. It crashes with a SegFault shortly after starting a new thread (via QThread), with a message: RTTI symbol not found for class 'SimClientPrivate' Are there incompatibilities of flto and cases where it cannot work? Thanks FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.) -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com: I have to disagree. I use lto in large production builds with great success. My use case is performance critical (games) and I build with -Ofast as well as lto and other heavy optimisations without problems, generating executable binaries of over a hundred megabytes in size when stripped and consisting of hundreds of translation units. Prior to 4.8 lto was incomplete and problematic but most bugs seem to have been eradicated by gcc 5.0. Interesting, because lto, even on Linux, causes quite some grievances up to te point distributions are refusing to enable it for their packages by default. Would you have any performance numbers (and I guess file sizes) comparing lto vs no-lto builds (all the other options remaining unchanged of course)? It'd be very interesting to see how lto actually changes things. Thanks! Ruben In my experience RTTI problems are more likely related to linking objects that were built with a different version of gcc using lto. Try rebuilding all your libraries and any linked objects with the same gcc version and settings. It may also be worth it to try static linking. Riot On 29 May 2015 12:21, Etienne Sandré-Chardonnal etienne.san...@m4x.org wrote: That's difficult to know, since the debugger seems to miss some information. The current function where the crash occurs is unknown :?? in the level 1 stack view For levels 2,3 and 4 I have the function name, but I have no access to the location in the code. Only level 5 of the stack is fully working in the debugger (all symbols + location in code) Level 2 is an default assignment operator of my ImageBuffer class. The class only contains basic types and std:: containers, no user defined pointers, so it likely crashes when copying one of the containers. The -flto is clearly not fully usable yet. I was trying it to see if it increases performance in a speed-critical app, which has a complex code and a lot of function calls between non-virtual classes. This seemed to be a good candidate for LTO. What did your debugger say? Was the segfault caused by dereferencing a pointer returned by a failed dynamic_cast? To my knowledge flto has never been working perfectly since g++ 4.8 on Windows: multiple definitions, undefined references, pointer-to-function referring garbage memory, valid pointers becoming null, random segment faults, etc... I strongly suggest you not use flto in production builds. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
I have to disagree. I use lto in large production builds with great success. My use case is performance critical (games) and I build with -Ofast as well as lto and other heavy optimisations without problems, generating executable binaries of over a hundred megabytes in size when stripped and consisting of hundreds of translation units. Prior to 4.8 lto was incomplete and problematic but most bugs seem to have been eradicated by gcc 5.0. In my experience RTTI problems are more likely related to linking objects that were built with a different version of gcc using lto. Try rebuilding all your libraries and any linked objects with the same gcc version and settings. It may also be worth it to try static linking. Riot On 29 May 2015 12:21, Etienne Sandré-Chardonnal etienne.san...@m4x.org wrote: That's difficult to know, since the debugger seems to miss some information. The current function where the crash occurs is unknown :?? in the level 1 stack view For levels 2,3 and 4 I have the function name, but I have no access to the location in the code. Only level 5 of the stack is fully working in the debugger (all symbols + location in code) Level 2 is an default assignment operator of my ImageBuffer class. The class only contains basic types and std:: containers, no user defined pointers, so it likely crashes when copying one of the containers. The -flto is clearly not fully usable yet. I was trying it to see if it increases performance in a speed-critical app, which has a complex code and a lot of function calls between non-virtual classes. This seemed to be a good candidate for LTO. What did your debugger say? Was the segfault caused by dereferencing a pointer returned by a failed dynamic_cast? To my knowledge flto has never been working perfectly since g++ 4.8 on Windows: multiple definitions, undefined references, pointer-to-function referring garbage memory, valid pointers becoming null, random segment faults, etc... I strongly suggest you not use flto in production builds. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
That's difficult to know, since the debugger seems to miss some information. The current function where the crash occurs is unknown :?? in the level 1 stack view For levels 2,3 and 4 I have the function name, but I have no access to the location in the code. Only level 5 of the stack is fully working in the debugger (all symbols + location in code) Level 2 is an default assignment operator of my ImageBuffer class. The class only contains basic types and std:: containers, no user defined pointers, so it likely crashes when copying one of the containers. The -flto is clearly not fully usable yet. I was trying it to see if it increases performance in a speed-critical app, which has a complex code and a lot of function calls between non-virtual classes. This seemed to be a good candidate for LTO. What did your debugger say? Was the segfault caused by dereferencing a pointer returned by a failed dynamic_cast? To my knowledge flto has never been working perfectly since g++ 4.8 on Windows: multiple definitions, undefined references, pointer-to-function referring garbage memory, valid pointers becoming null, random segment faults, etc... I strongly suggest you not use flto in production builds. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
Oh I can absolutely see why you might not want to enable it by default, but in special cases where performance is worth the extra manual fuss of working around its very occasional bugs, it's quite useful. So I did a release build of our current primary project without LTO, and compared it to our build with LTO. Before I present the results though, some peculiarities of our build process to be aware of: - We compile all our libraries statically, including libc and libc++ under windows. In addition we make heavy use of templates and Boost, so our resulting generated object size is large. - We include large binary blobs in our release executable itself (game music, textures) which increase the final binary size considerably. I subtract these (approximate) blob sizes from the final result for the code size difference comparison. - There are no debugging symbols included in our release build and the binary is stripped with strip -spv. - This version is 32bit only. You may see very different results for 64bit builds. Project properties: - 27000LOC without includes - 200 compiled objects for the linker - 26 pre-compiled libraries, 9.27MB - 47 binary blobs, 140MB - 127 compiled objects (project code), remainder of the size - A lot of heavy optimisation options, including -Ofast and several unsafe maths optimisations, but also tweaked optimiser params giving the optimiser much higher memory limits and function size growth etc than would be allowed by default. Here's a pastebin of all optimisation flags used: http://pastebin.com/R6dNCMhP - The only difference between the tests was disabling -fuse-linker-plugin and -flto for the without-lto build. Both were built from scratch. Comparison results: Without LTO.With LTODifference Build time 20m 51s 28m 2s +34% Object size 152,243,279 bytes 169,512,168 bytes +11% Object size minus blobs 4,977,685 bytes 22,246,874 bytes+346% File size 152,585,216 bytes 150,350,848 bytes -2% File size minus blobs 5,319,622 bytes 3,085,254 bytes -42% Benchmark time 1m 53s 1m 47s -6% This is probably not a very good generalisation for the use of LTO since my use-case is quite specific, but these numbers might be of interest nevertheless. In summary, you're basically paying 34% more compilation time (from scratch - haven't compared partial compiles) and 300% more pre-linked objet size, and in return getting 42% smaller compiled code size and 6% performance improvement. In games, absolutely any measurable performance improvement is worth any amount of extra compile-time cost, but that may not be true for other fields. Regards, Riot On 29 May 2015 at 13:27, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com: I have to disagree. I use lto in large production builds with great success. My use case is performance critical (games) and I build with -Ofast as well as lto and other heavy optimisations without problems, generating executable binaries of over a hundred megabytes in size when stripped and consisting of hundreds of translation units. Prior to 4.8 lto was incomplete and problematic but most bugs seem to have been eradicated by gcc 5.0. Interesting, because lto, even on Linux, causes quite some grievances up to te point distributions are refusing to enable it for their packages by default. Would you have any performance numbers (and I guess file sizes) comparing lto vs no-lto builds (all the other options remaining unchanged of course)? It'd be very interesting to see how lto actually changes things. Thanks! Ruben In my experience RTTI problems are more likely related to linking objects that were built with a different version of gcc using lto. Try rebuilding all your libraries and any linked objects with the same gcc version and settings. It may also be worth it to try static linking. Riot On 29 May 2015 12:21, Etienne Sandré-Chardonnal etienne.san...@m4x.org wrote: That's difficult to know, since the debugger seems to miss some information. The current function where the crash occurs is unknown :?? in the level 1 stack view For levels 2,3 and 4 I have the function name, but I have no access to the location in the code. Only level 5 of the stack is fully working in the debugger (all symbols + location in code) Level 2 is an default assignment operator of my ImageBuffer class. The class only contains basic types and std:: containers, no user defined pointers, so it likely crashes when copying one of the containers. The -flto is clearly not fully usable yet. I was trying it to see if it increases performance in a
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
Hi, This worked, the program compiles fine now. It crashes with a SegFault shortly after starting a new thread (via QThread), with a message: RTTI symbol not found for class 'SimClientPrivate' Are there incompatibilities of flto and cases where it cannot work? Thanks FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.) -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
What g++ version were you using? What were the exact command lines you used to
build your program?
--
Best regards,
lh_mouse
2015-05-21
-
发件人：Etienne Sandré-Chardonnal etienne.san...@m4x.org
发送日期：2015-05-21 14:55
收件人：mingw-w64-public
抄送：
主题：[Mingw-w64-public] Multiple definition issue with -flto,
MinGW-w64 4.9.1
Dear all,
I tested -flto on a pretty large program today, and it fails with a
multiple definition error:
./release\scenehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0):
multiple definition of `BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0):
first defined here
./release\scenehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0):
multiple definition of `non-virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0):
first defined here
./release\scenehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0):
multiple definition of `virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0):
first defined here
./release\bufferstream.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0):
multiple definition of `BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0):
first defined here
./release\bufferstream.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0):
multiple definition of `virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0):
first defined here
./release\bufferstream.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0):
multiple definition of `non-virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0):
first defined here
I have found this bug
https://sourceware.org/bugzilla/show_bug.cgi?id=12762, but it was not
followed-up since 2013 and gcc 4.6/4.7
Is this a bug or a problem in my code? The class BufferStream is defined
only once in a header file, and uses a default destructor. It is detailed
below.
Thanks,
Etienne
class BufferStream : public std::iostream
{
public:
BufferStream();
std::streampos size() const { return streamBuf.size(); }
const char * data() const { return streamBuf.data(); }
std::vectorchar getBufferAndClear() { return
streamBuf.getBufferAndClear(); }
private:
class StreamBuf : public std::streambuf
{
public:
explicit StreamBuf();
~StreamBuf() { }
int overflow(int c = EOF);
std::streampos size() const { return pptr()-pbase(); }
const char * data() const { return pbase(); }
std::vectorchar getBufferAndClear();
private:
std::vectorchar buffer;
};
StreamBuf streamBuf;
};
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
The gcc version is in the title (4.9.1), it is an official MinGW-w64 posix-seh build The command line is like this (I have stripped several -D and -I command line options, otherwise it is intact) *Compiler:* g++ -c -pipe -fno-keep-inline-dllexport -O3 -Wformat-nonliteral -std=gnu++11 -mfpmath=sse -march=corei7-avx -mtune=corei7-avx -msse4 -mavx -ftree-vectorize -fno-math-errno -funsafe-math-optimizations -fno-trapping-math -fno-exceptions *-flto *-frtti -Wall -Wextra -fexceptions -mthreads -o release\appparameters.o ..\..\ocean\source\appparameters.cpp *Linker* g++ -Wl,-s -Wl,-s -Wl,-subsystem,console -mthreads -o release\myapp.exe object_script.myapp.Release -lglu32 -lopengl32 -lgdi32 -luser32 -lIlmImf -lHalf -lIlmThread -lIex -lImath -lz -ldbghelp -lslapi -LD:/Qt/Desktop/Qt/5.4.1/lib -lQt5Widgets -lQt5Gui -lQt5Network -lQt5Xml -lQt5Concurrent -lQt5Core release\myapp_res.o The script file only contains all the .o Everything compiles link fine without -flto What g++ version were you using? What were the exact command lines you used to build your program? -- Best regards, lh_mouse 2015-05-21 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
Dear all,
I tested -flto on a pretty large program today, and it fails with a
multiple definition error:
./release\scenehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0):
multiple definition of `BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0):
first defined here
./release\scenehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0):
multiple definition of `non-virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0):
first defined here
./release\scenehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0):
multiple definition of `virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0):
first defined here
./release\bufferstream.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0):
multiple definition of `BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0):
first defined here
./release\bufferstream.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0):
multiple definition of `virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0):
first defined here
./release\bufferstream.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0):
multiple definition of `non-virtual thunk to BufferStream::~BufferStream()'
./release\consolehandler.o (symbol from
plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0):
first defined here
I have found this bug
https://sourceware.org/bugzilla/show_bug.cgi?id=12762, but it was not
followed-up since 2013 and gcc 4.6/4.7
Is this a bug or a problem in my code? The class BufferStream is defined
only once in a header file, and uses a default destructor. It is detailed
below.
Thanks,
Etienne
class BufferStream : public std::iostream
{
public:
BufferStream();
std::streampos size() const { return streamBuf.size(); }
const char * data() const { return streamBuf.data(); }
std::vectorchar getBufferAndClear() { return
streamBuf.getBufferAndClear(); }
private:
class StreamBuf : public std::streambuf
{
public:
explicit StreamBuf();
~StreamBuf() { }
int overflow(int c = EOF);
std::streampos size() const { return pptr()-pbase(); }
const char * data() const { return pbase(); }
std::vectorchar getBufferAndClear();
private:
std::vectorchar buffer;
};
StreamBuf streamBuf;
};
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
This was a mistake from my last post. The -flto was passed to the linker, and I get this error. You didn't specify -flto in your linker command line. Add that and try again. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.) -- Best regards, lh_mouse 2015-05-21 - 发件人：Etienne Sandré-Chardonnal etienne.san...@m4x.org 发送日期：2015-05-21 19:40 收件人：mingw-w64-public 抄送： 主题：Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1 This was a mistake from my last post. The -flto was passed to the linker, and I get this error. You didn't specify -flto in your linker command line. Add that and try again. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
You didn't specify -flto in your linker command line. Add that and try again. https://gcc.gnu.org/wiki/LinkTimeOptimization -- Best regards, lh_mouse 2015-05-21 - 发件人：Etienne Sandré-Chardonnal etienne.san...@m4x.org 发送日期：2015-05-21 15:24 收件人：mingw-w64-public 抄送： 主题：Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1 The gcc version is in the title (4.9.1), it is an official MinGW-w64 posix-seh build The command line is like this (I have stripped several -D and -I command line options, otherwise it is intact) *Compiler:* g++ -c -pipe -fno-keep-inline-dllexport -O3 -Wformat-nonliteral -std=gnu++11 -mfpmath=sse -march=corei7-avx -mtune=corei7-avx -msse4 -mavx -ftree-vectorize -fno-math-errno -funsafe-math-optimizations -fno-trapping-math -fno-exceptions *-flto *-frtti -Wall -Wextra -fexceptions -mthreads -o release\appparameters.o ..\..\ocean\source\appparameters.cpp *Linker* g++ -Wl,-s -Wl,-s -Wl,-subsystem,console -mthreads -o release\myapp.exe object_script.myapp.Release -lglu32 -lopengl32 -lgdi32 -luser32 -lIlmImf -lHalf -lIlmThread -lIex -lImath -lz -ldbghelp -lslapi -LD:/Qt/Desktop/Qt/5.4.1/lib -lQt5Widgets -lQt5Gui -lQt5Network -lQt5Xml -lQt5Concurrent -lQt5Core release\myapp_res.o The script file only contains all the .o Everything compiles link fine without -flto What g++ version were you using? What were the exact command lines you used to build your program? -- Best regards, lh_mouse 2015-05-21 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
Using -flto-partition=1to1 or -flto-partition=none generally works around these issues. I typically use 1to1 when using lto for anything since I can rarely even get gcc to bootstrap correctly with lto without it. On Thu, May 21, 2015 at 8:09 AM, lh_mouse lh_mo...@126.com wrote: FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.) -- Best regards, lh_mouse 2015-05-21 - 发件人：Etienne Sandré-Chardonnal etienne.san...@m4x.org 发送日期：2015-05-21 19:40 收件人：mingw-w64-public 抄送： 主题：Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1 This was a mistake from my last post. The -flto was passed to the linker, and I get this error. You didn't specify -flto in your linker command line. Add that and try again. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
