Re: [Mingw-w64-public] -shared vs. -mdll
http://comments.gmane.org/gmane.comp.gnu.mingw.user/9155 On Thu, Mar 20, 2014 at 10:08 PM, Martin Mitáš wrote: > > Hi list, > > with mingw-w64, I'm used to build DLLs with gcc linker option -mdll. > > I am currently playing with CMake as I consider to leave manually > maintained Makefiles behind me. It seems CMake prefers -shared over > -mdll. I cannot find any docs how the two options differ. So, which one > is the right one for "normal DLL"? Should I convince CMake that -mdll is > better? > > And one bonus question (a bit off-topic for this list): If I should to > convince it, do you know how? When I tried to use > > set(CMAKE_SHARED_LINKER_FLAGS "-mwindows -mdll") > > then I've got an error: > > gcc.exe: error: shared and mdll are not compatible > > I also tried cmake -LAH to see where -shared comes from but it does not > uncover that. > > > Thanks for any info or pointers, > Martin > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] -shared vs. -mdll
Hi list, with mingw-w64, I'm used to build DLLs with gcc linker option -mdll. I am currently playing with CMake as I consider to leave manually maintained Makefiles behind me. It seems CMake prefers -shared over -mdll. I cannot find any docs how the two options differ. So, which one is the right one for "normal DLL"? Should I convince CMake that -mdll is better? And one bonus question (a bit off-topic for this list): If I should to convince it, do you know how? When I tried to use set(CMAKE_SHARED_LINKER_FLAGS "-mwindows -mdll") then I've got an error: gcc.exe: error: shared and mdll are not compatible I also tried cmake -LAH to see where -shared comes from but it does not uncover that. Thanks for any info or pointers, Martin -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler
On Thu, Mar 20, 2014 at 8:33 AM, Jim Michaels wrote: > > but I thought that it was said here that the win32 version does not work > with sjlj in a stable way - yet? > You've resurrected a month old thread with an email that is 100% non-sequitur. At no point in this this thread has anyone mentioned sjlj. Also, you are talking about some object or product without any indication of what "it" is, nor who it was "here" who said "that" about "it". Would it be possible for you to connect the dots please? > > > From: Kai Tietz > To: "mingw-w64-public@lists.sourceforge.net" > > Sent: Thursday, February 20, 2014 1:14 AM > Subject: Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler > > 2014-02-20 1:16 GMT+01:00 Ciro Cornejo : >> Seriously? !!! >> >> >> >> Come on guys, this makes the compiler unusable. > > What? > >> >> >> ...but as long as you're making a toy compiler, would you consider making >> one that does not support pthreads and so avoids this problem? >> > > Why we should make a compiler which doesn't support pthreads? pthreads > is a user-library and it is up to you to use it or not. > >> >> Thanks. >> >> >> >> Hi! Sorry for the interruption, but you may want to take at least a few >> seconds >> >> to look into some recent license changes for the software you're about to >> >> install. > > What license-changes? Yes, winpthread uses a more liberal license for > developers as other win32 based pthread libraries do. So yes, it is a > BSD license, and therefore you might need to mention that you are > using is it. This is just fair. > >> >> >> Parts of the "winpthreads" library will be compiled into every binary file >> (EXE > > That isn't true. First this applies only to gcc-version built with > posix-threading model. For it, either it is linked in as shared > library, or if you request it as static library. > If you don't want to rely on posix-threading-model, then simply don't > use it and choose a toolchain buiild with win32-threading mode (by the > way the default configuration). > > I would advice you to look in more detail to license issues. MS > compiler has them, and gcc & mingw(-w64) do so too. You will be > wondering what other licenses you are using for just building a simple > hello-world-application with mingw(-w64). For getting an idea you > might to take a look to the COPYING.MinGW-w64-runtime license. > > You seem to mix here the term "free software" with "free for nothing > software", and "copy other people's work without acknowledge it". > >> or DLL) you create. It's a necessary evil that is currently required in >> order to >> >> provide support for threads and concurrency in programs compiled by GCC. >> >> >> >> The license for winpthreads requires you to reproduce its text in every >> copy >> or >> >> substantial portion of the winpthreads library that you distribute. This >> means >> >> that even if you just want to distribute a single small executable, >> created >> with >> >> TDM-GCC (or any winpthreads-based GCC release), you must include a copy of >> that >> >> license. >> > > INAL, but in general you might be right. If you want to be fair, you > should need to mention other derived work you are using in your > application too. We see this pretty liberal, nevertheless people like > you are showing to us that we might should reconsider about that. > >> >> Check the license out in the file "COPYING.winpthreads.txt", which will be > > Where you see COPYING.winpthreads.txt file? It isn't part of > winpthread. We have there a file named "COPYING". I assume you are > referring to that. > > Regards, > Kai > > > -- > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > -- > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this f
Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler
but I thought that it was said here that the win32 version does not work with sjlj in a stable way - yet? > > From: Kai Tietz >To: "mingw-w64-public@lists.sourceforge.net" > >Sent: Thursday, February 20, 2014 1:14 AM >Subject: Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler > > >2014-02-20 1:16 GMT+01:00 Ciro Cornejo : >> Seriously? !!! >> >> >> >> Come on guys, this makes the compiler unusable. > >What? > >> >> >> ...but as long as you're making a toy compiler, would you consider making >> one that does not support pthreads and so avoids this problem? >> > >Why we should make a compiler which doesn't support pthreads? pthreads >is a user-library and it is up to you to use it or not. > >> >> Thanks. >> >> >> >> Hi! Sorry for the interruption, but you may want to take at least a few >> seconds >> >> to look into some recent license changes for the software you're about to >> >> install. > >What license-changes? Yes, winpthread uses a more liberal license for >developers as other win32 based pthread libraries do. So yes, it is a >BSD license, and therefore you might need to mention that you are >using is it. This is just fair. > >> >> >> Parts of the "winpthreads" library will be compiled into every binary file >> (EXE > >That isn't true. First this applies only to gcc-version built with >posix-threading model. For it, either it is linked in as shared >library, or if you request it as static library. >If you don't want to rely on posix-threading-model, then simply don't >use it and choose a toolchain buiild with win32-threading mode (by the >way the default configuration). > >I would advice you to look in more detail to license issues. MS >compiler has them, and gcc & mingw(-w64) do so too. You will be >wondering what other licenses you are using for just building a simple >hello-world-application with mingw(-w64). For getting an idea you >might to take a look to the COPYING.MinGW-w64-runtime license. > >You seem to mix here the term "free software" with "free for nothing >software", and "copy other people's work without acknowledge it". > >> or DLL) you create. It's a necessary evil that is currently required in >> order to >> >> provide support for threads and concurrency in programs compiled by GCC. >> >> >> >> The license for winpthreads requires you to reproduce its text in every copy >> or >> >> substantial portion of the winpthreads library that you distribute. This >> means >> >> that even if you just want to distribute a single small executable, created >> with >> >> TDM-GCC (or any winpthreads-based GCC release), you must include a copy of >> that >> >> license. >> > >INAL, but in general you might be right. If you want to be fair, you >should need to mention other derived work you are using in your >application too. We see this pretty liberal, nevertheless people like >you are showing to us that we might should reconsider about that. > >> >> Check the license out in the file "COPYING.winpthreads.txt", which will be > >Where you see COPYING.winpthreads.txt file? It isn't part of >winpthread. We have there a file named "COPYING". I assume you are >referring to that. > >Regards, >Kai > > >-- >Managing the Performance of Cloud-Based Applications >Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >Read the Whitepaper. >http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >___ >Mingw-w64-public mailing list >Mingw-w64-public@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > >-- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
