From: Rolf E. <rol...@gm...> - 2008-02-23 18:43:43
|
I am still struggeling to build gcc-4.3 on mingw. Using the release candidate I get the following error during the configure run at stage2: configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 77 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 Looking at intl/config.log: configure:2118: checking for C compiler default output file name configure:2121: /k/Data/Development/gcc-cvs/build_native/./prev-gcc/xgcc -B/k/Data/Development/gcc-cvs/ build_native/./prev-gcc/ -B/mingw/mingw32/bin/ -g -O2 -D__USE_MINGW_ACCESS conftest.c >&5 C:\Programme\msys_1.0\mingw\bin\ld.exe: crt2.o: No such file: No such file or directory collect2: ld returned 1 exit status Any hint? Rolf |
From: Brian D. <br...@de...> - 2008-02-23 19:03:33
|
Rolf Ebert wrote: > /k/Data/Development/gcc-cvs/build_native/./prev-gcc/xgcc > -B/k/Data/Development/gcc-cvs/ > build_native/./prev-gcc/ -B/mingw/mingw32/bin/ -g -O2 > -D__USE_MINGW_ACCESS conftest.c >&5 > C:\Programme\msys_1.0\mingw\bin\ld.exe: crt2.o: No such file: No such > file or directory > collect2: ld returned 1 exit status The "-B/mingw/mingw32/bin/" there implies that gcc expects to find its GCC_EXEC_PREFIX at $prefix/$target which is the default in the absense of a sysroot. If you're using Cygwin as a build environment then you can fix this simply by creating the dir $prefix/$target/ which contains 3 symlinks for bin, include, and lib each pointing to ../bin, ../include, and ../lib resp. You also might be able to solve this by configuring --with-sysroot=/mingw but a sysroot for a native compiler bootstrap strikes me as a fundamentally broken idea. Brian |
From: Brian D. <br...@de...> - 2008-02-23 19:05:56
|
Brian Dessent wrote: > of a sysroot. If you're using Cygwin as a build environment then you Er, duh, symlinks of course won't work for the xgcc. Well, you could copy the dirs instead I suppose, or try using a sysroot. Brian |
From: Earnie B. <ea...@us...> - 2008-02-24 01:19:21
|
Quoting Brian Dessent <br...@de...>: > Brian Dessent wrote: > >> of a sysroot. If you're using Cygwin as a build environment then you > > Er, duh, symlinks of course won't work for the xgcc. > Yep, thats where MSYS comes in handy. It doesn't created .lnk files and uses a copy instead. Could be enhanced to use reparse points for directories on NTFS as has been discussed. Earnie |
From: Hans S. <han...@gm...> - 2008-02-24 02:35:25
|
i haven't read through the whole discussion, but if you simply need symlinks it might be interesting to know that nt supports them natively and these real symlinks work with whatever you throw them at: http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx |
From: Rolf E. <rol...@gm...> - 2008-02-24 16:35:48
|
Brian Dessent schrieb: > Rolf Ebert wrote: > >> /k/Data/Development/gcc-cvs/build_native/./prev-gcc/xgcc >> -B/k/Data/Development/gcc-cvs/ >> build_native/./prev-gcc/ -B/mingw/mingw32/bin/ -g -O2 >> -D__USE_MINGW_ACCESS conftest.c >&5 >> C:\Programme\msys_1.0\mingw\bin\ld.exe: crt2.o: No such file: No such >> file or directory >> collect2: ld returned 1 exit status > > The "-B/mingw/mingw32/bin/" there implies that gcc expects to find its > GCC_EXEC_PREFIX at $prefix/$target which is the default in the absense > of a sysroot. If you're using Cygwin as a build environment then you > can fix this simply by creating the dir $prefix/$target/ which contains > 3 symlinks for bin, include, and lib each pointing to ../bin, > ../include, and ../lib resp. You also might be able to solve this by > configuring --with-sysroot=/mingw but a sysroot for a native compiler > bootstrap strikes me as a fundamentally broken idea. I consider both ideas (manually setting symlinks and providing --with-sysroot) as broken. For the time being I solved it by copying the necessary files from /mingw/lib into the prev-gcc folder. I don't think that -B/mingw/mingw32/bin is relevant for the discussion as my build path is also provided -B/k/Data/Development/gcc-cvs/build_native/./prev-gcc/ The question is: should stage1 already build all the files (e.g. crt2.o, libkernel32.a, etc.) or are the later stages supposed to find these files in /mingw/lib? BTW, I am using msys as build environment (with access to some cygwin binaries that are broken on msys like tar) Rolf |
From: Brian D. <br...@de...> - 2008-02-24 19:05:10
|
Rolf Ebert wrote: > The question is: should stage1 already build all the files (e.g. crt2.o, > libkernel32.a, etc.) or are the later stages supposed to find these > files in /mingw/lib? Those are part of mingw-runtime and w32api respectively. They aren't part of gcc, so why would any gcc stage build them? For a native bootstrap they should all be used from /mingw/lib for every stage. Or are you talking about a combined tree build? In that case it will still fail because of the chicken and egg problem. Brian |
From: Brian D. <br...@de...> - 2008-02-24 03:41:13
|
Hans Schmucker wrote: > i haven't read through the whole discussion, but if you simply need > symlinks it might be interesting to know that nt supports them > natively and these real symlinks work with whatever you throw them at: > http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx Sigh. No. Junctions are nothing like symlinks, don't perpetuate that nonsense. <http://article.gmane.org/gmane.comp.gnu.mingw.msys/4178> Brian |
From: Hans S. <han...@gm...> - 2008-02-24 16:45:06
|
Does it make any difference here? He only wants to link to directories... |
From: Keith M. <kei...@us...> - 2008-02-24 18:18:46
|
On Sunday 24 February 2008 16:45, Hans Schmucker wrote: > Does it make any difference here? Yes, it does. What you actually said was | if you simply need symlinks it might be interesting to know that nt | supports them natively... which is just blatantly untrue, since | ...and these real symlinks... are nothing of the sort, and | ...work with whatever you throw them at applies *only* if "whatever you throw them at" happens to be a directory. > He only wants to link to directories... This may be so, in this particular instance. However, *real* symbolic links apply equally to files and directories, and your sweeping statement suggests that this feature is available on WinNT, which is not the case; (and even in the case of reparse points, what tool does Microsnot provide, AS A STANDARD OS COMPONENT, for creating them)? What is available, as Earnie had already stated, is the "reparse point", (a.k.a. "junction"). By throwing your hat in the ring, to qualify this as a "symlink", serves no additional useful purpose, beyond an apparent attempt to "perpetuate the nonsense" that WinNT somehow provides a real symbolic link capability. Regards, Keith. |
From: Hans S. <han...@gm...> - 2008-02-24 20:13:38
|
The words real and symlink were only thrown in there to distinguish them from the "emulated symlinks" provided by Cygwin, nothing more.... sheesh |
From: Keith M. <kei...@us...> - 2008-02-26 21:09:27
|
On Sunday 24 February 2008 20:13, Hans Schmucker wrote: [w.r.t. equivalence of WinNT's reparse points and symbolic links] > The words real and symlink were only thrown in there to distinguish > them from the "emulated symlinks" provided by Cygwin, nothing > more.... sheesh So, why mention it at all? AFAIK, Cygwin's "emulated symlinks" do actually provide a fair emulation of real symlinks, (provided that it is a Cygwin application which is interpreting them). Reparse points, (a.k.a. "junction points") are something else entirely; their closest analogue in the Unix world would be loop-back mounts, which exhibit rather different properties from symbolic links. Regards, Keith. |
From: Hans S. <han...@gm...> - 2008-02-26 23:16:15
|
I have to admit that I'm a bit helpless dealing with the likes of you, but let's see: 1. Rolf wants to build something (doesn't matter what) with MinGW and emulated symlinks don't work, because MinGW is not a cygwin application. 2. Brian points out to him that he isn't dealing with a Cygwin application. 3. I point out that he could use junctions (never mind how I called them, I did post a link), which offers a solution. 4. You start your series of lectures without offering any information that would be helpful to Rolf with the apparent aim to drive me off this list Is that an accurate summary? |
From: Keith M. <kei...@us...> - 2008-02-29 21:08:24
|
On Tuesday 26 February 2008 23:16, Hans Schmucker wrote: > I have to admit that I'm a bit helpless dealing with the likes of > you, ... Well then, that feeling is mutual. > ... but let's see: > > 1. Rolf wants to build something (doesn't matter what) with MinGW and > emulated symlinks don't work, because MinGW is not a cygwin > application. I don't see how that is in any way relevant; AFAICT, at no time did Rolf enquire about MinGW's capability to work with symlinks. > 2. Brian points out to him that he isn't dealing with a Cygwin > application. On the contrary, Brian suggested a kludge to work around the problem Rolf was facing. The kludge was based on the use of symlinks, which would require the use of Cygwin, or perhaps, as Earnie pointed out, in the particular circumstances of Rolf's issue, a similar kludge using reparse points might be effective *without* requiring Cygwin. > 3. I point out that he could use junctions... ...which basically was just a reiteration of the option Earnie had already pointed out. (That's not a criticism; maybe you hadn't seen Earnie's response, when you posted yours). > (never mind how I called them, ... You said they were *real* symlinks, which is technically inaccurate. > I did post a link), ... ...which was useful, thanks; no one is disputing that. > which offers a solution. No; it offers a possible mechanism for implementing a kludge. A kludge is *never* a solution, IMO. However, it may be expedient to adopt a kludge, in order to work around some problem for which no immediate solution is apparent; the distinction may be considered pedantic, so let's not dwell on it. > 4. You start your series of lectures... My postings had nothing whatsoever to do with `lecturing'... > ...without offering any information that would be helpful to Rolf ... ...neither was it intended to be helpful to Rolf, who had already stated that he was not interested in any such form of kludged work around; it was intended to correct the technically inaccurate statements that you had made. This was in no way intended as any form of personal affront; it was merely correction and clarification of information for the sake of preserving the integrity of the list archives. These archives are a valuable resource for future reference, which is why it is important that such corrections of misleading information are posted, (and why it *does* matter that the incorrect information you posted was not allowed to pass into the archives without such accompanying correction). > with the apparent aim to drive me off this list Driving you, or anyone else, off the list could never have been further from my mind; if I'd wanted to do that, I could simply have invoked my administrative privilege, and excluded all posts from your address. I'm sorry that you are so easily offended, when someone, (Brian and I, on this occasion), points out and corrects technical inaccuracies in some information you've posted on the list. There are many places on the Internet, where you can find bad advice on using MinGW; we do not want this list to be one of them. Had I myself posted technically inaccurate information, I should have been grateful for someone to correct my misconceptions; (indeed this has happened before, and I have no doubt it may happen again, for none of us is infallible). Regards, Keith. |