From: Schuster, J. (N-Compaq) <joe...@lm...> - 2002-10-24 21:15:57
|
For anyone using the STLport with mingw; I have successfully compiled and used it with mingw in both dll and static variances. If anyone needs help, or a pre-compiled version, E-mail me directly. Joel (next project - compiling MFC :) -----Original Message----- From: Oscar Fuentes [mailto:of...@wa...] Sent: Thursday, October 24, 2002 2:30 PM To: min...@li... Subject: Re: [Mingw-users] using the gcc c++ libraries and licensing "Schuster, Joel (N-Compaq)" <joe...@lm...> writes: [snip] > I'm still not sure if I can use the gnu c++ libraries. I've read all > the licensing stuff, and from that I would say 'NO', but there is this > little caveat in the headers - > " > // As a special exception, you may use this file as part of a free software > // library without restriction. Specifically, if other files instantiate > // templates or use macros or inline functions from this file, or you > compile > // this file and link it with other files to produce an executable, this > // file does not by itself cause the resulting executable to be covered by > // the GNU General Public License. This exception does not however > // invalidate any other reasons why the executable file might be covered by > // the GNU General Public License. > " > -- whatever that means. "Free Software" as exercised by GNU is about giving to *users* the right to inspect and modify the software. They go so far that their license (the GPL) has a viral effect. Once you combine GPL code with yours, your application must be distributed under the GPL (or compatible) license. However, GNU wants to become the dominant software provider, and they acknowledge that the viral effect of the GPL is not a good thing to achieve that goal. So they invented the LGPL, which lets you to use a LGPL'ed library with your code without infecting your entire project with the GPL. However, the LGPL'ed library, seen as an isolated and monolithic piece of software, forces you to distribute its binary expression as if it were under the GPL. This means that you can call routines on a LGPL library, but you must distribute your binaries on such a way that lets people to *inspect* and *modify* that LGPL'ed library (not your own code). Usually, this is accomplished with dll's. You distribute that fancy LGPL'ed library compiled as a dll and provide its sources to your users. They can learn how the library works, they can modify it, they can re-build the dll and make it to work with your application without knowing nothing about your own code. The above doesn't work for C++ template code. As C++ templates are compiled and mixed with the code that uses them, there is no way of allowing users to modify how the C++ library works and make that changes work with your application unless you provide your own source code. This means that the LGPL, for C++ template libraries, is the same thing than the GPL. As GNU wants that commercial vendors use its C++ compiler together with its Standard C++ Library, they made that exception to the libstdc++ GPL license. That exception allows to use libstdc++ on closed source projects and distribute the binaries without restrictions. This is what the "runtime exception" is about. The questions and answers on the libstdc++ license webpage should clarify that beyond any doubt. Specifically: Q: I see. So, what restrictions are there on programs that use the library? A: None. We encourage such programs to be released as open source, but we won't punish you or sue you if you choose otherwise Finally, please note that if you are your own customer (that is, if you create software to be used in-house), all the GPL and LGPL issues are irrelevant. > So I think that I'm going to go use the STLport for my STL and > I/O support since they have a open license like mingw... STLPort has a prestige of being a good implementation of the SC++L. > Now to just get that to compile.... Yup. That's a libstdc++ advantage. It works with g++ out of the box. Maybe STLPort is a bit outdated wrt the latest g++ releases and, more precisely, to MinGW, but it should work without too much pain. > Oh, yeah. And about this: > > "Defense"? Really? If you work making or improving killing machines > I'll stop giving assistance to you for anything that is not of > interest to all MinGW users." > > Don't worry, my stuff monitors location of space debris and makes sure that > it doesn't collide with the space shuttle... :) I'm a conscientious objector > when it comes to the guns and killing and stuff. I'm glad to hear this. Thanks. -- Oscar ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Hadi A. <ha...@cb...> - 2004-06-03 17:17:03
|
Hi, I am using W2k SP4. I have STLport-5.0-0125.tar.gz and want to compile it under MinGW (gcc version 3.2.3 (mingw special 20030504-1)). I think I could compile the library without any problem. But, if I try to link the sample program with the dlls, such as libstlport_mingw32.dll.5.0, the program doesn't run properly. Here I link the program with the dlls. D:\STLport\test\eh>g++ -o test.exe test.cpp -O2 -Id:/stlport/stlport -Ld:/stlport/lib -lstlport_mingw32 Info: resolving __ZN4_STL4coutE by linking to __imp___ZN4_STL4coutE (auto-import) D:\STLport\test\eh>test vector: But, if I link the program with the static library : D:\STLport\test\eh>g++ -o test.exe test.cpp -O2 -Id:/stlport/stlport -Ld:/stlport/lib -lstlport_mingw32_static D:\STLport\test\eh>test vector: 1 1 set1 : 1 set2 : 1 Anybody knows the problem ? Thanks, Hadi http://www.hadi.webaddicted.net/ -- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.642 / Virus Database: 410 - Release Date: 3/25/2004 |
From: Oscar F. <of...@wa...> - 2002-10-24 21:54:56
|
"Schuster, Joel (N-Compaq)" <joe...@lm...> writes: [snip] > (next project - compiling MFC :) MFC relies on compiler extensions and deviations from the C++ standard. GCC does not implement such "features". -- Oscar |
From: Jerry v. D. <jv...@at...> - 2002-10-24 23:01:01
|
> For anyone using the STLport with mingw; I have successfully compiled and > used it with mingw in both dll and static variances. If anyone needs help, > or a pre-compiled version, E-mail me directly. Actually, I have a fair bit of C++ code compiled with gcc 2.95.3 and STLPort. I have been postponing moving to gcc 3.2 as I would have to rebuild STLPort for it. If you are using gcc 3.2 I'd be interested to know if you ran into anything specific. > (next project - compiling MFC :) I'll guess I will see you on a wxWindows list next :-) -- -- Jerry van Dijk | email: jv...@at... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Luke D. <cod...@ho...> - 2002-10-25 11:56:02
|
----- Original Message ----- From: "Oscar Fuentes" <of...@wa...> To: <min...@li...> Sent: Friday, October 25, 2002 5:55 AM Subject: Re: [Mingw-users] STLport > "Schuster, Joel (N-Compaq)" <joe...@lm...> writes: > > [snip] > > > (next project - compiling MFC :) > > MFC relies on compiler extensions and deviations from the C++ > standard. GCC does not implement such "features". > > -- > Oscar I am sure this is true, but it would be interesting to know how far Joel gets with this. Just out of interest, do you have an example of one of these extensions? I expect there may be a few #pragmas but what else? Luke |
From: Oscar F. <of...@wa...> - 2002-10-25 18:37:17
|
"Luke Dunstan" <cod...@ho...> writes: > > > (next project - compiling MFC :) > > > > MFC relies on compiler extensions and deviations from the C++ > > standard. GCC does not implement such "features". >=20 > I am sure this is true, but it would be interesting to know how far > Joel gets with this. Just out of interest, do you have an example of > one of these extensions? I expect there may be a few #pragmas but > what else? Quoting from the Borland C++ help files: Turn this option on to compile code that is compatible with the Microsoft foundation classes (MFC). Among other things, the compiler makes the following adjustments to be compatible with MFC: Accepts spurious semicolons in a class scope Allows anonymous structs Uses the old-style scoping resolution in for loops Allows methods to be declared with a calling convention, but leaves off the calling convention in the definition Tries the operator new if it cannot resolve a call to the operator new[=A0] Lets you omit the operator & on member functions Allows a const class that is passed by value to be treated as a trivial conversion, not as a user conversion Allows you to use a cast to a member pointer as a selector for overload resolution, even if the qualifying type of the member pointer is not derived from the class in which the member function is declared Accepts declarations with duplicate storage in a class, as in extern "C" typedef Accepts and ignores #pragma comment(linker, "...") directives --=20 Oscar |