From: <jsv...@be...> - 2001-03-28 00:46:12
|
Hello I've been trying to get a few things building lately, and after overcoming the initial problems with getting configure to accept my gcc an actual compiler with the ability to create executables, i've been having trouble with sed reporting some errors in the later stages of configurations (when generating makefiles and config.hs) output is like this: V:\BIN\SED.EXE: Unterminated `s' command V:\BIN\SED.EXE: Unknown command V:\BIN\SED.EXE: file conftest.s1 line 1: Unknown command This is all very informative, but it doesn't say much about WHERE it actually fails, and configure is not a very self-explanatory script. I am also not a sed wizard. I am using sed 2.05 binary provided by 'Mikey' on ftp.franken.de in sed205-ming.tar.bz2, under bash 2.04 for dos, provided at djgpp distribution sites. (bash is one of the things i am trying to build ;) I have also tried to build a later version of sed, in case the problem was due to my sed being outdated, but naturally, sed failed to configure itself ;) 1. Is this a common mingw-specific problem? 2. Is there a nice little workaround? I find it shockingly improbable that i should be the first to experience this. |
From: <dan...@ya...> - 2001-03-28 04:45:10
|
--- jsv...@be... wrote: > Hello > > I've been trying to get a few things building lately, and after > overcoming the initial problems with getting configure to accept my > gcc an actual compiler with the ability to create executables, i've > been having trouble with sed reporting some errors in the later > stages of configurations (when generating makefiles and config.hs) > > output is like this: > > V:\BIN\SED.EXE: Unterminated `s' command > V:\BIN\SED.EXE: Unknown command > V:\BIN\SED.EXE: file conftest.s1 line 1: Unknown command > > This is all very informative, but it doesn't say much about WHERE > it actually fails, and configure is not a very self-explanatory script. I > am also not a sed wizard. > > I am using sed 2.05 binary provided by 'Mikey' on ftp.franken.de in > sed205-ming.tar.bz2, under bash 2.04 for dos, provided at djgpp > distribution sites. (bash is one of the things i am trying to build ;) > > I have also tried to build a later version of sed, in case the problem > was due to my sed being outdated, but naturally, sed failed to > configure itself ;) > > 1. Is this a common mingw-specific problem? > 2. Is there a nice little workaround? > I have found that the sed that is distributed with cygwin is more dependable than other "native" versions. Danny _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: Lloyd D. <ll...@ga...> - 2001-03-29 21:55:42
|
i build my c++ dll (base.dll). i made a program with 2 cpp file, let them call a.cc & b.cc wich both intensively use my DLL. when i link "gcc -o a.exe a.o b.o -L. -lbase" the b file produce a lot of undefined reference error. i swap the order and any other such things. but the error remain in b. worst there is an undefined reference error on function called also in a....... what does this could mean ? i agree i mistaken, but in wich way ? do you have any idea ? |
From: Greg C. <chi...@mi...> - 2001-03-30 01:21:30
|
Lloyd Dupont wrote: > > i build my c++ dll (base.dll). > i made a program with 2 cpp file, let them call a.cc & b.cc > wich both intensively use my DLL. > when i link "gcc -o a.exe a.o b.o -L. -lbase" Try 'g++' instead of 'gcc' for linking C++. > the b file produce a lot of undefined reference error. i swap the order > and any other such things. but the error remain in b. worst there is an > undefined reference error on function called also in a....... > what does this could mean ? > i agree i mistaken, but in wich way ? do you have any idea ? Try posting a minimal test case so that others can reproduce the problem. |
From: Lloyd D. <ll...@ga...> - 2001-03-31 00:16:51
|
i try to use C++ exception and i encounter 2 problems. 1./ (maybe it's normal ?) my catch ignore hierarchie if i have class A; class B: public A; try { throw new B; } catch(A * a) { // will never be reached.... 2./ i don't know why, in my real progralm, try/catch don't work. i catch nothing, Windows pop-up an abnormal program termination and the program close. unfortunately, and this is very curious, i cannot manage to make a little test case. whatever example i write, it work. i catch and test progam exit normally. do you have any idea ? |
From: Travis H. <ki...@op...> - 2001-03-31 00:57:54
|
I just recompiled a program with newer MinGW GCC build (2.95.2-3) and was surprised to find after recompiling that the program required libstdc++.dll to run. The previous MinGW GCC build (2.95.2-20001116) didn't have this problem. How can I avoid having to bundle the extra dll file with program and can that file be redistributed in meantime ? |
From: <dan...@ya...> - 2001-03-31 04:25:55
|
--- Travis Howell <ki...@op...> wrote: > I just recompiled a program with newer MinGW GCC build (2.95.2-3) and was > surprised to find after recompiling that the program required libstdc++.dll > to run. The previous MinGW GCC build (2.95.2-20001116) didn't have this > problem. How can I avoid having to bundle the extra dll file with program > and can that file be redistributed in meantime ? > > Both libstdc++.dll.a and libstdc++.a are in distro. The version of ld you download from sourceforge tries to use shared libraries if possible. That is, if you write g++ -o test.exe test.o -lfoo and both libfoo.dll.a and libfoo.a are in search path, it will use libfoo.dll.a. If you do not want libfoo.dll.a to have precedence over libfoo.a , add the -static switch: g++ -o test.exe test.o -static -lfoo Paul Sokolovsky, is that about right? Danny _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: <dan...@ya...> - 2001-03-31 04:57:13
|
--- Danny Smith <dan...@ya...> wrote: > > --- Travis Howell <ki...@op...> wrote: > I just recompiled a > program with newer MinGW GCC build (2.95.2-3) and was > > surprised to find after recompiling that the program required libstdc++.dll > > to run. The previous MinGW GCC build (2.95.2-20001116) didn't have this > > problem. How can I avoid having to bundle the extra dll file with program > > and can that file be redistributed in meantime ? > > > > > > Both libstdc++.dll.a and libstdc++.a are in distro. The version of ld you > download from sourceforge tries to use shared libraries if possible. That > is, > if you write > g++ -o test.exe test.o -lfoo > and both libfoo.dll.a and libfoo.a are in search path, it will use > libfoo.dll.a. > > If you do not want libfoo.dll.a to have precedence over libfoo.a , add the > -static switch: > g++ -o test.exe test.o -static -lfoo > Oops, -static is a linker switch. It should be: g++ -o test.exe test.o -Wl,-static -lfoo > Paul Sokolovsky, is that about right? > > Danny > > > > _____________________________________________________________________________ > http://my.yahoo.com.au - My Yahoo! > - Have news, stocks, weather, sports and more in one place. > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users _____________________________________________________________________________ http://my.yahoo.com.au - My Yahoo! - Have news, stocks, weather, sports and more in one place. |
From: Paul S. <pa...@is...> - 2001-03-31 23:47:27
|
Hello Danny, Danny Smith <dan...@ya...> wrote on Saturday, March 31, 2001: >> If you do not want libfoo.dll.a to have precedence over libfoo.a , add the >> -static switch: >> g++ -o test.exe test.o -static -lfoo >> DS> Oops, -static is a linker switch. It should be: DS> g++ -o test.exe test.o -Wl,-static -lfoo Nope, --static should be passed to gcc. Compiler must know that static build takes place. But well, it should pass it to ld, and that doesn't happen. That's bug. Here's a workaround: g++ --shared -Wl,--shared Here's a fix: --- specs.old Sun Apr 1 02:23:41 2001 +++ specs Sun Apr 1 02:23:15 2001 @@ -17,7 +17,7 @@ *link: -%{mwindows:--subsystem windows} %{mconsole:--subsystem console} %{shared: %{mdll: %eshared and mdll are not compatible}} %{shared: --shared} %{mdll:--dll} %{shared|mdll: -e _DllMainCRTStartup@12} +%{static:--static} %{mwindows:--subsystem windows} %{mconsole:--subsystem console} %{shared: %{mdll: %eshared and mdll are not compatible}} %{shared: --shared} %{mdll:--dll} %{shared|mdll: -e _DllMainCRTStartup@12} *lib: %{pg:-lgmon} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32 -ladvapi32 -lshell32 >> Paul Sokolovsky, is that about right? >> >> Danny -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Paul S. <pa...@is...> - 2001-03-31 23:43:53
|
Hello Danny, Danny Smith <dan...@ya...> wrote on Saturday, March 31, 2001: DS> --- Travis Howell <ki...@op...> wrote: > I just recompiled a DS> program with newer MinGW GCC build (2.95.2-3) and was >> surprised to find after recompiling that the program required libstdc++.dll >> to run. The previous MinGW GCC build (2.95.2-20001116) didn't have this >> problem. How can I avoid having to bundle the extra dll file with program >> and can that file be redistributed in meantime ? >> >> DS> Both libstdc++.dll.a and libstdc++.a are in distro. The version of ld you DS> download from sourceforge tries to use shared libraries if possible. That is, DS> if you write DS> g++ -o test.exe test.o -lfoo DS> and both libfoo.dll.a and libfoo.a are in search path, it will use DS> libfoo.dll.a. DS> If you do not want libfoo.dll.a to have precedence over libfoo.a , add the DS> -static switch: DS> g++ -o test.exe test.o -static -lfoo DS> Paul Sokolovsky, is that about right? Yep. What I'd like to add is note why it is so. Using shared libraries in preference over static is default ld behavior for any target which supports shared libraries. Since gnu-win32 for some time supports them quite good, that's how its ld works also (i.e. that's how cygwin linker works). Shared libstdc++ was provided after observation that statically-linked C++ apps are too big. Also, if project consists of several C++ dlls, it means there's large code duplication (I have project with 8 dlls, linking them dynamically saves ~1mb of code; so much dlls are used because it's a hell to link 3mb dll). DS> Danny -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Paul S. <pa...@is...> - 2001-04-01 00:11:35
|
Hello Travis, Travis Howell <ki...@op...> wrote on Saturday, March 31, 2001: TH> I just recompiled a program with newer MinGW GCC build (2.95.2-3) and was TH> surprised to find after recompiling that the program required libstdc++.dll TH> to run. The previous MinGW GCC build (2.95.2-20001116) didn't have this TH> problem. How can I avoid having to bundle the extra dll file with program TH> and can that file be redistributed in meantime ? I wonder how many people download and install something without reading release notes and changelog? They mention many interesting things, among them the fact that all those packages are NOT new builds, but just repackagings of old good Mumit Khan's gcc-2.95.2-1. Surprisingly, it says about libstdc++.dll "problem" also... -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Travis H. <ki...@op...> - 2001-04-01 00:30:39
|
> Hello Travis, > > Travis Howell <ki...@op...> wrote on Saturday, March 31, 2001: > > TH> I just recompiled a program with newer MinGW GCC build (2.95.2-3) and was > TH> surprised to find after recompiling that the program required libstdc++.dll > TH> to run. The previous MinGW GCC build (2.95.2-20001116) didn't have this > TH> problem. How can I avoid having to bundle the extra dll file with program > TH> and can that file be redistributed in meantime ? > > I wonder how many people download and install something without > reading release notes and changelog? They mention many > interesting things, among them the fact that all those packages are > NOT new builds, but just repackagings of old good Mumit Khan's > gcc-2.95.2-1. Surprisingly, it says about libstdc++.dll "problem" > also... > > -- > Paul Sokolovsky, IT Specialist > http://www.brainbench.com/transcript.jsp?pid=11135 Well if the files been updated and changed then it is at least a new release. As for reason I didn't read the release notes as first is that they seemed to be hidden than other programs, I'm used to changelog/release notes been in main directory or docs directory and it is easy to miss release notes on sourceforge too if you use direct links to files which bypass note at top of page. I was actually looking in the news section and files directory for the releases notes the other day, just found the right place by chance last night. |
From: Franco B. <fra...@we...> - 2001-03-30 04:49:46
|
Am Freitag, 30. M=E4rz 2001 00:53 schrieb Lloyd Dupont: > i build my c++ dll (base.dll). > i made a program with 2 cpp file, let them call a.cc & b.cc > wich both intensively use my DLL. > when i link "gcc -o a.exe a.o b.o -L. -lbase" > > the b file produce a lot of undefined reference error. i swap the order > and any other such things. but the error remain in b. worst there is an > undefined reference error on function called also in a....... > what does this could mean ? > i agree i mistaken, but in wich way ? do you have any idea ? Sounds like a problem with the include files. Do a.cc and b.cc include the same headers in the same order ? Ciao, Franco |