From: <dan...@ya...> - 2000-12-04 21:42:26
|
--- Paul Sokolovsky <pf...@us...> wrote: > Hello Danny, > > Danny Smith wrote on Monday, December 04, 2000: > >> After "alpha freeze", I'm going to release next binutils > packages > >> as beta. > > DS> Other more important concern that I have is that mingw binutils > drift > DS> too far from main binutils cvs stream. > > Well, not quite, there's just some additional patches maintained > in addition to current CVS. I do regular updates, so there's no > branching. > > DS> Related to this: IMHO more > DS> scrutiny/testing needed by wider user base (i.e. cygwin). > Shouldn't > DS> the alpha changes at least be submitted to binutils before > releasing > DS> mingw beta? > > So far I submitted all my patches except auto-import. All of > them, > except addition of more default excludes were accepted, and > latest cygwin release has them. For excludes, original patch was > changed two or three times so I didn't bothered DJ Delorie with it, > wanting it to stabilize (btw, DJ now works on non-win32-related > project, so it won't be easy to catch him, and he seems to be head > maintainer of PE code for binutils). > > As you remember, I asked suggestion on how best to solve that > re-exporting of symbols from static libs problem. Finally I, consider > adding just libstdc++ to default includes is adequate. It is system > lib, implicitly added to the tail of link libraries. So, if there's > some lib which defines one (and only) of same symbols in object > (imlib > case), whereas libstdc++ has some (unresolved) symbol in the module > with already found (in the lib) symbol, we'll have conflict. For all > the rest (user) libraries, this can be solved by adhering to simple > rule: put implibs after statics in command line. So, this should > work, > I expect your feedback and go for re-submitting it. > Thanks for the clarification. I will do some more testing with c++, excluding libstdc++ from auto-import. Could --exclude-libs= be an explicit command line option? Of course, if libstdc++ was dll that would solve a lot of problems. I have been testing STLPort (SGI) iostream lib and STL headers (better locale support, native file memory mapping, templatized iostreams, and when built as dll, great reduction in size of executable). > Finally, auto-import is likely to be long way to accepting. > That's > why I need argument like "code was alpha-tested with mingw and no > problems were reported". I thought that was the strategy. Just wanted to confirm. Thanks. > > DS> Regards > DS> Danny > > > > -- > Paul Sokolovsky, IT Specialist > http://www.brainbench.com/transcript.jsp?pid=11135 > > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > http://lists.sourceforge.net/mailman/listinfo/mingw-dvlpr _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: Earnie B. <ear...@ya...> - 2000-12-08 15:06:19
|
> > > > "Should we distribute dynamic libstdc++ with gcc or as > > the separate package?" > > I've mixed views and have been trying to narrow down to answer this. My stance is to tends to be to use static libraries as an update in a dynamic library can't change the operation of the program. However, there are times when dynamic libraries are useful and IMO this is one of those times. As the libstdc++ affects all C++ binaries then all C++ binaries will benefit by one being smaller in size, two being immediately updateable when bugs are fixed. Yes, we should provide a libstdc++.dll.a and accompanying libstdc++.dll as well as a libstdc++.a for static linking. This shouldn't be a separate package, it should be part of the standard package. Cross compilers shouldn't have a problem with dll's as they must use the executable that builds for the target. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
From: Paul G. <pga...@te...> - 2000-12-09 01:27:01
|
Hi folks, No doubt this will likely generate a lot of criticism...hopefully that is where it will end. I want to make it clear up front; A great deal of what I have written below is based on a feeling...something that doesn't have any sort of "empirical" evidence behind it...or as some would say "it is not grounded on anything authoritative enough". This is acceptable to me...as I have yet to find a feeling that can be called "empiraclly authoritative" (an oxymoron if ever I heard of one, especially when it comes to talking about feelings). In my experience when something doesn't seem "empiraclly authoritative" it is usually a personal warning. On 8 Dec 2000, at 7:06, the Illustrious Earnie Boyd wrote: > > > > > > "Should we distribute dynamic libstdc++ with gcc or > > > as > > > the separate package?" > > > > > I've mixed views and have been trying to narrow down to answer > this. My stance is to tends to be to use static libraries as an > update in a dynamic library can't change the operation of the > program. >However, there are times when dynamic libraries are > useful and IMO this is one of those times. As the libstdc++ > affects all C++ binaries then all C++ binaries will benefit by > one being smaller in size, two being immediately updateable when > bugs are fixed. I understand...however, if minimizing the size of the executables is important (and I agree that it is), then it would seem that as a side-effect we would need to change default activity of compile/link phase to strip excess symbols...we already give the option for this, but it is not a default characteristic of mingw-gcc or of ld. The last thing I want to do is re-invent the msvc/c++ compiler in the form of mingw. And, down the road, it doesn't seem so unreasonable to think that, "hey, since we already have libstdc++ available as a .dll, why not simply make mingw ld default to .dll lib generation?" This doesn't feel right. > > Yes, we should provide a libstdc++.dll.a and accompanying > libstdc++.dll as well as a libstdc++.a for static linking. This > shouldn't be a separate package, it should be part of the > standard package. Cross compilers shouldn't have a problem with > dll's as they must use the executable that builds for the target. Yes, they shouldn't, but what if the cross-compiler can't deal with .dlls? Doesn't that mean that we become responsible for supplying the necessary .dll support and subsequently maintaining that support? (Not that I am afraid of supporting such a thing...I have a great deal of confidence in the mingw developers team and am certain that it can be done if someone should choose to do so.) Case in point...it's been awhile, but afaik, Linux (as an example) has no way to deal with or test .dlls on the local, plain vanilla platform, nor can Linux (exception=Cygwin for Linux), in the form of server, typically deal with .dlls on a client machine w/o a lot of added support. Who is to supply that support? Default performance characteristics for plain vanilla Linux based platform (more and more common these days) don't allow for such things. The closest that a plain vanilla Linux OS can get to a .dll file is the .so libs. Is there a .so distribution lib for libstdc++? If not, why not? Mingw ld can generate .so files natively, it can not, however test those .so files natively. Thus, any .so files that are generated would need to be tested on the targetted Linux platform, wouldn't they? Finally, afaik, there are two different types of .dlls that may be generated under Mingw. The MS compatible .dll and the Mingw compatible .dll. Which version would the libstdc++.dll be compatible with? Mingw or msvc? It can't be both unless we supply both an ms compatible .dll AND a mingw compatible .dll for libstdc++ libs. If we do supply these, it would then, afaict, become necessary to support both of them as well as to differentiate between them within the gcc-runtime distribution. In closing, I will yield to majority decision here, I just want to make it clear that I have some serious doubts about the practicality of including libstdc++.dll as part of the mingw runtime or mingw-gcc distribution. Peace, Paul G. > > Cheers, > > ===== > Earnie Boyd > mailto:ear...@ya... > > --- <http://earniesystems.safeshopper.com> --- > --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- > --- Minimalist GNU for Windows <http://www.mingw.org/> --- > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ > _______________________________________________ MinGW-dvlpr > mailing list Min...@li... > http://lists.sourceforge.net/mailman/listinfo/mingw-dvlpr > Nothing real can be threatened. Nothing unreal exists. |
From: <dan...@ya...> - 2000-12-10 21:11:41
|
Hello Paul --- Paul Sokolovsky <pf...@us...> wrote: > Hello Danny, > > Danny Smith wrote on Wednesday, December 06, 2000: > > > auto-export is a feature to have symbols *exported* without marking > them so explicitly. That work for some time for code > symbols, recently was extended to data symbols and now > I'm > trying to make it not export unnecassary junk. > auto-import is a feature to *import* symbols without explicitly > marking them so. This worked always for code symbols, and > I added non-trivial processing to work for data symbols > too. > > Are you sure you auto-import? If so, it's great news, because > AFAIK, it was tested only on some trivial examples. > With fltk, which exports much data (fonts, static data members in classes), I have successfully tested these 4 cases: Build lib with dllexports in code 0.0 build regression tests with dllimports in code 0.1 build regression tests without dllimports (--auto-import) Build lib without declspecs (auto-export) 1.0 build regression tests with dllimports in code 1.1 build regression tests without dllimports (--auto-import) All method succeeded! with --auto-import links giving me the appropriate warnings Danny _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: Paul S. <pf...@us...> - 2000-12-11 00:36:23
|
Hello Danny, Danny Smith wrote on Monday, December 11, 2000: DS> Hello Paul DS> --- Paul Sokolovsky <pf...@us...> wrote: > Hello DS> Danny, >> >> Danny Smith wrote on Wednesday, December 06, 2000: >> >> >> auto-export is a feature to have symbols *exported* without marking >> them so explicitly. That work for some time for code >> symbols, recently was extended to data symbols and now >> I'm >> trying to make it not export unnecassary junk. >> auto-import is a feature to *import* symbols without explicitly >> marking them so. This worked always for code symbols, and >> I added non-trivial processing to work for data symbols >> too. >> >> Are you sure you auto-import? If so, it's great news, because >> AFAIK, it was tested only on some trivial examples. >> DS> With fltk, which exports much data (fonts, static data members in DS> classes), I have successfully tested these 4 cases: DS> Build lib with dllexports in code DS> 0.0 build regression tests with dllimports in code DS> 0.1 build regression tests without dllimports (--auto-import) DS> Build lib without declspecs (auto-export) DS> 1.0 build regression tests with dllimports in code DS> 1.1 build regression tests without dllimports (--auto-import) DS> All method succeeded! with --auto-import links giving me the DS> appropriate warnings Good news. What OS you ran it on? DS> Danny DS> _____________________________________________________________________________ DS> http://clubs.yahoo.com.au - Yahoo! Clubs DS> - Join a club or build your own! DS> _______________________________________________ DS> MinGW-dvlpr mailing list DS> Min...@li... DS> http://lists.sourceforge.net/mailman/listinfo/mingw-dvlpr -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: <dan...@ya...> - 2000-12-11 02:06:45
|
> DS> With fltk, which exports much data (fonts, static data members in > DS> classes), I have successfully tested these 4 cases: > > DS> Build lib with dllexports in code > DS> 0.0 build regression tests with dllimports in code > DS> 0.1 build regression tests without dllimports > (--auto-import) > DS> Build lib without declspecs (auto-export) > DS> 1.0 build regression tests with dllimports in code > DS> 1.1 build regression tests without dllimports > (--auto-import) > > DS> All method succeeded! with --auto-import links giving me the > DS> appropriate warnings > > Good news. What OS you ran it on? NT4, sp6 To add to the "auto" namespace confusion, auto-import may be interpreted by some as the ability to automatically link to dll without implib, building one on the fly. My test of this auto-facility failed for data symbol names. Danny > > DS> Danny > > > > DS> > _____________________________________________________________________________ > DS> http://clubs.yahoo.com.au - Yahoo! Clubs > DS> - Join a club or build your own! > DS> _______________________________________________ > DS> MinGW-dvlpr mailing list > DS> Min...@li... > DS> http://lists.sourceforge.net/mailman/listinfo/mingw-dvlpr > > > > > -- > Paul Sokolovsky, IT Specialist > http://www.brainbench.com/transcript.jsp?pid=11135 > > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > http://lists.sourceforge.net/mailman/listinfo/mingw-dvlpr _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: <dan...@ya...> - 2000-12-29 22:36:37
|
Hello Paul Happy New Year --- Paul Sokolovsky <pf...@us...> wrote: > Hello Danny, > > Danny Smith wrote on Wednesday, December 06, 2000: > > > [] > DS> Here is a C example of what I mean, using libiberty.a: > > DS> /* cdll.c */ > DS> #include <libiberty.h> > DS> #include <stdio.h> > DS> void my_pwd(){ > DS> char* dll_pwd=getpwd(); > DS> printf("pwd from dll: %s \n", dll_pwd); > DS> return; > DS> } > > DS> /* test.c */ > DS> #include <libiberty.h> > DS> void my_pwd(); > > DS> int main(){ > DS> char* liberty_pwd=getpwd(); > DS> my_pwd(); > DS> return 1; > DS> } > > DS> Using this script > > DS> cc -c cdll.c > DS> gcc -shared -Wl,--out-implib,libmycdll.a,--output-def,mycdll.def > \ > DS> -o mycdll.dll cdll.o -liberty > DS> gcc -c main.c > DS> rem This works > DS> gcc -o test1.exe main.o -L. -lmycdll -liberty > DS> test1 > DS> rem This doesn't, even though getpwd is exported from dll > DS> rem The auto-import warning tells us why > DS> gcc -o test2.exe main.o -L. -lmycdll > DS> test2 > > DS> The ouput-def looks like this: > DS> EXPORTS > DS> _xexit_cleanup @1 DATA > DS> getpwd @2 DATA > DS> my_pwd @3 > DS> xcalloc @4 > DS> xexit @5 DATA > DS> xmalloc @6 DATA > DS> xmalloc_set_program_name @7 > DS> xrealloc @8 > > [] > > I cannot reproduce this problem with all the latest binutils. I > have > > EXPORTS > _xexit_cleanup @1 DATA > getpwd @2 > my_pwd @3 > xcalloc @4 > xexit @5 > xmalloc @6 > xmalloc_failed @7 > xmalloc_set_program_name @8 > xrealloc @9 > > and both cases build successfully. Btw, there's no getpwd() in the > libiberty as distributed with Mumit's gcc, so I'll replace it with > latest from binutils. > > If you'll answer, please cc: to me, I seem to have mail routing > probs with pf...@us..., from which I subscribed. > > For above example I am using binutils-20001103, ld-20001204, libbfd-20001204 from your distros and static libiberty from binutils-20001212 (my build). I still cannot get "lastest" ld-20001217 from your distro to work (access violation in libbfd-2.10.91.dll). The diff file for ld-20001217 is identical to diff file for ld-20001204 and no debugging info in binary so haven't been able to find source of access violation. The "latest" binutils-20001225.zip at SourceForge is an empty file. Can you suggest anything to help me track down my problem. Cheers Danny _____________________________________________________________________________ http://au.classifieds.yahoo.com/au/car/ - Yahoo! Cars - Buy, sell or finance a car.. |
From: Paul S. <pf...@us...> - 2001-01-17 21:23:13
|
Hello Danny, Sorry for the long delay with reply. In this country we have New Year/Xmas holidays spanning half-January, and I since the problems you reported weren't obvious and instead rather tangled and inter-related, I just don't have time to untwine them. But here's some feedback. Danny Smith wrote on Friday, December 29, 2000: [] DS> I still cannot get "lastest" ld-20001217 from your distro to work DS> (access violation in libbfd-2.10.91.dll). The diff file for ld-20001217 DS> is identical to diff file for ld-20001204 and no debugging info in DS> binary so haven't been able to find source of access violation. DS> The "latest" binutils-20001225.zip at SourceForge is an empty file. Ok, yet at previous millenium I killed my work mingw32 installation and installed all from latest packages, to investigate the segfault problem. What I found however is that binutils-20001225.zip contained broken as, which complained something about ia64. That's why I didn't bother to re-release it. Well, next time I touched it I did cvs update of as ChangeLog and saw it was buggy commit which was fixed. I decided to put up a new binutils release, which took rather long time, because I wasn't able to cvs update all the packages due to total brokedness of my phone line during holidays. I did it on the latest weekend just to find that as still broken and complains about architecture. I spent half-day to haunt this bug and look how stupid it was: - i[456]86) cpu_type=i386 arch=i386;; + i[3456]86) cpu_type=i386 arch=i386;; Well, so I made new package and installed it. With it I finally was able to see ld segfaulting. Dunno. In the meantime, today I tried to release new binutils but there's seem to problem with SF release stuff again. DS> Can you suggest anything to help me track down my problem. If since that time there were any news, tell me, otherwise I'll have a look as time permits. I usually always do make install before producing package, so I don't know why I didn't notice that segfault before. DS> Cheers DS> Danny -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Paul S. <pf...@us...> - 2000-12-05 00:13:26
|
Hello Danny, Danny Smith wrote on Tuesday, December 05, 2000: DS> Thanks for the clarification. I will do some more testing with c++, DS> excluding libstdc++ from auto-import. Could --exclude-libs= be an DS> explicit command line option? If you will add it ;-) DS> Of course, if libstdc++ was dll that would solve a lot of problems. That's exactly what I wanted to ask - I have an idea to provide both static and dynamic libstdc++ with gcc. This will mean dunamic will be selected by default (unless linked with --static). Any comments? DS> I DS> have been testing STLPort (SGI) iostream lib and STL headers (better DS> locale support, native file memory mapping, templatized iostreams, and DS> when built as dll, great reduction in size of executable). Do you mean that STLport can be drop-in replacement for libstdc++? Then, we could provide dynamic libstdc++ as separate package, and user will be able to chose which implementation to use. Btw, do you have an idea - maybe, latest libstdc++ also catched up with standard? >> Finally, auto-import is likely to be long way to accepting. >> That's >> why I need argument like "code was alpha-tested with mingw and no >> problems were reported". DS> I thought that was the strategy. Just wanted to confirm. Thanks. >> >> DS> Regards >> DS> Danny -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Paul G. <pga...@te...> - 2000-12-05 03:52:55
|
On 5 Dec 2000, at 2:13, the Illustrious Paul Sokolovsky wrote: > Hello Danny, > > Danny Smith wrote on Tuesday, December 05, 2000: > > > DS> Thanks for the clarification. I will do some more testing > with c++, DS> excluding libstdc++ from auto-import. Could > --exclude-libs= be an DS> explicit command line option? > > If you will add it ;-) > > DS> Of course, if libstdc++ was dll that would solve a lot of > problems. > > That's exactly what I wanted to ask - I have an idea to > provide > both static and dynamic libstdc++ with gcc. This will mean > dunamic will be selected by default (unless linked with > --static). Any comments? Hmm...if you're talking about modifying gcc/g++ default setting to dynamic, I disagree. People cross-compiling won't appreciate having to generate mingw or msvc based .dlls before they can generate say an .so or something similar for their Unix g++ cross-compile. Just my humble opinion... Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Paul S. <pf...@us...> - 2000-12-06 10:04:14
|
Hello Paul, Paul Garceau wrote on Tuesday, December 05, 2000: PG> On 5 Dec 2000, at 2:13, the Illustrious Paul Sokolovsky wrote: >> Hello Danny, >> >> Danny Smith wrote on Tuesday, December 05, 2000: >> >> >> DS> Thanks for the clarification. I will do some more testing >> with c++, DS> excluding libstdc++ from auto-import. Could >> --exclude-libs= be an DS> explicit command line option? >> >> If you will add it ;-) >> >> DS> Of course, if libstdc++ was dll that would solve a lot of >> problems. >> >> That's exactly what I wanted to ask - I have an idea to >> provide >> both static and dynamic libstdc++ with gcc. This will mean >> dunamic will be selected by default (unless linked with >> --static). Any comments? PG> Hmm...if you're talking about modifying gcc/g++ default setting PG> to dynamic, I disagree. No, I'm not talking about that. In fact, gcc (to be precise, ld) must be changed to have static linking by default. PG> People cross-compiling won't appreciate having to generate PG> mingw or msvc based .dlls before they can generate say an .so or PG> something similar for their Unix g++ cross-compile. I don't understand this concern. PG> Just my humble opinion... Once again, if there're some concerns based on real experience, we can make it separate package. PG> Peace, PG> Paul G. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Paul G. <pga...@te...> - 2000-12-07 01:02:16
|
Hi folks, On 6 Dec 2000, at 12:04, the Illustrious Paul Sokolovsky wrote: > Hello Paul, > > Paul Garceau wrote on Tuesday, December 05, 2000: > > > > PG> On 5 Dec 2000, at 2:13, the Illustrious Paul Sokolovsky > wrote: > > >> Hello Danny, > >> > >> Danny Smith wrote on Tuesday, December 05, 2000: > >> > >> > >> DS> Thanks for the clarification. I will do some more testing > >> with c++, DS> excluding libstdc++ from auto-import. Could > >> --exclude-libs= be an DS> explicit command line option? > >> > >> If you will add it ;-) > >> > >> DS> Of course, if libstdc++ was dll that would solve a lot of > >> problems. > >> > >> That's exactly what I wanted to ask - I have an idea to > >> provide > >> both static and dynamic libstdc++ with gcc. This will mean > >> dunamic will be selected by default (unless linked with > >> --static). Any comments? > > PG> Hmm...if you're talking about modifying gcc/g++ > default setting PG> to dynamic, I disagree. allow me to rephrase: if you're talking about modifying ld default linking to always link a .dll as the default lib type, I disagree. ld, unless otherwise informed, will always assume static libs are being linked. It also assumes that any thing with the switch -l in the command line (again unless otherwise informed) is to be found in the lib/ directory and has a postfix of ".a" (static lib) and a prefix of "lib". As an example: When -lmoldname is invoked on the command line: gcc foo.c -ofoo.exe -lmoldname ld makes the following assumptions: A) "look for a file called "libmoldname.a" in the default lib/ directory. B) If "libmoldname.a" is found then B.1) "link this file" into foo.exe (else) B.2) if "libmoldname.a" is not found then B.3) generate an exception stating that there is nothing called "libmoldname.a" in the default /lib directory and exit linking phase accordingly. --- end of linking process The above process is what defines "default" linking for "ld". Changing this default linking to use .dlls instead of static (.a) libs is, imho, a mistake. One that can only be compounded given the most recent release of Xfree86(v4); a release which requires DirectX to generate X-Windows graphics output. Xfree86 has already been implemented and tested for Linux under Cygwin (-mno-cygwin not set), and it is not very long now before people will want to use Xfree86 while having the -mno-cygwin switch set. Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Paul S. <pf...@us...> - 2000-12-07 10:26:03
|
Hello Paul, Paul Garceau wrote on Thursday, December 07, 2000: PG> allow me to rephrase: PG> if you're talking about modifying ld default linking to always PG> link a .dll as the default lib type, I disagree. Paul, forgive me, I have nothing against you, I direct this only to this specific question. But - your point is invalid. I have no idea where you get what you wrote below, but it is not grounded on anything authoritative enough. I hope you forgive me if I leave fighting your dynamic linking prejudices for yourself. Official documentation, cygwin and binutls mailing lists, real behaviour exhibited by GNU binutils on some full-fledged system, source code are all your friends. And of course, xfree and -mno-cygwin have no relation to the original question, which is: "Should we distribute dynamic libstdc++ with gcc or as the separate package?" Your comments on *that* question are welcome. PG> Peace, PG> Paul G. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 P.S. I've got some directx app, and 've got no idea what headers/lib I should use there were so many ports announced - I hope to got consultation from you on this question. |
From: Paul G. <pga...@te...> - 2000-12-08 03:10:07
|
Hi folks, Paul S., thank you for the clarification. It was unclear what you were trying to say, so I attempted to deduce based on what little data I had available... On 7 Dec 2000, at 12:26, the Illustrious Paul Sokolovsky wrote: > Hello Paul, > > Paul Garceau wrote on Thursday, December 07, 2000: > > PG> allow me to rephrase: > > PG> if you're talking about modifying ld default > linking to always PG> link a .dll as the default lib type, I > disagree. > > Paul, forgive me, I have nothing against you, I direct this > only > to this specific question. > But - your point is invalid. I have no > idea where you get what you wrote below, but it is not grounded > on anything authoritative enough. I hope you forgive me if I > leave fighting your dynamic linking prejudices for yourself. Hmm...another breakdown in communication...ah well... > Official documentation, cygwin and binutls mailing lists, real > behaviour exhibited by GNU binutils on some full-fledged system, > source code are all your friends. And of course, xfree and > -mno-cygwin have no relation to the original question, which is: > > "Should we distribute dynamic libstdc++ with gcc or as > the separate package?" Static libs are being distributed as part of the mingw gcc distribution. I don't have any problem with continuing in this vein. In simpler terms, I can see no reason to change the current configuration of the gcc distribution where libstdc++ is concerned. Primarily because it is, first and foremost, a static library build, not dynamic. As to creating and including a dynamic library for libstdc++ (libstdc++.dll) with mingw-gcc, I disagree as it destroys cross- platform portability...as more and more people build cross- compilers, more problems will arise which center or revolve around libstdc++ distributions. Our best bet, imho, is to do everything we can to minimize these sort of problems. If someone desperately needs a dynamic library for libstdc++ (strange as that may seem), they are probably intelligent enough to build it from the existing static libraries and/or libstdc++ source code. This way we are not required to support it, nor, imho, should we as mingw developers. Of course, this doesn't mean someone can't spend the time building such a dynamic library; it only means we, as mingw developers won't support it. There is nothing stopping anyone from submitting such things to the mingw repository, is there? See (http://sourceforge.net/projects/mingwrep/) Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |