From: Shadow2531 <sha...@tb...> - 2005-10-17 21:10:03
|
Is free() implemented differently with mingw compared to other compilers like msvc++. (mingw 3.4.2 specifically) stdlib.h just imports it from libmsvcrt.a right? Or, does it import it directly from msvcrt.dll on my WinXP sp2 system? Where or how can I see exactly what free in libmsvcrt.a is doing? As much info as possible would be appreciated. Since you'll probably want to know why I want to know about free(); I'm investigating a quirky effect that calling free(NULL) has on the Windows low-memory message popup. Calling free(NULL) makes the popup disappear instantly. It's a pain trying to explain what I'm talking about, so I would rather focus on how free() is coded than the quirk. (tried to search the archives, but servers were unresponsive) Thanks Shadow2531 |
From: Michael G. <mg...@te...> - 2005-10-17 21:28:30
|
> Is free() implemented differently with mingw compared to other=20 > compilers like msvc++. (mingw 3.4.2 specifically) No. > stdlib.h just imports it from libmsvcrt.a right? Or, does it import it=20 > directly from msvcrt.dll on my WinXP sp2 system? There is a misconception here - libmsvcrt.a is created from msvcrt.dll. > Where or how can I see exactly what free in libmsvcrt.a is doing? As=20 > much info as possible would be appreciated. The sources are part of the MSVC++ compiler -- at least it was that way with MSVC++ 6.0. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Shadow2531 <sha...@tb...> - 2005-10-18 00:46:33
|
Michael Gerdau wrote: >> Is free() implemented differently with mingw compared to other >> compilers like msvc++. (mingw 3.4.2 specifically) > > No. Thanks. >> stdlib.h just imports it from libmsvcrt.a right? Or, does it import it >> directly from msvcrt.dll on my WinXP sp2 system? > > There is a misconception here - libmsvcrt.a is created from msvcrt.dll. Would that be like doing reimp on msvcrt.dll to get libmsvcrt.a? Shadow2531 |
From: Shadow2531 <sha...@tb...> - 2005-10-19 15:13:01
|
Michael Gerdau wrote: >>Is free() implemented differently with mingw compared to other >>compilers like msvc++. (mingw 3.4.2 specifically) > > There is a misconception here - libmsvcrt.a is created from msvcrt.dll. In asking elsewhere, someone asked me, "By the way, why doesn't mingw include its own runtime libraries? It seems very curious that they reuse the VC versions. How is that licensed? Meanwhile, their not giving you source code for the libraries will make debgging certain classes of problems quite difficult." Could you address that question. Thanks Shadow2531 |
From: Daniel A. <dan...@gm...> - 2005-10-19 15:27:03
|
T24gMTAvMTkvMDUsIFNoYWRvdzI1MzEgPHNoYWRvdzI1MzFAdGJicy5uZXQ+IHdyb3RlOgo+Cj4g TWljaGFlbCBHZXJkYXUgd3JvdGU6Cj4gPj5JcyBmcmVlKCkgaW1wbGVtZW50ZWQgZGlmZmVyZW50 bHkgd2l0aCBtaW5ndyBjb21wYXJlZCB0byBvdGhlcgo+ID4+Y29tcGlsZXJzIGxpa2UgbXN2Yysr LiAobWluZ3cgMy40LjIgc3BlY2lmaWNhbGx5KQo+ID4KPiA+IFRoZXJlIGlzIGEgbWlzY29uY2Vw dGlvbiBoZXJlIC0gbGlibXN2Y3J0LmEgaXMgY3JlYXRlZCBmcm9tIG1zdmNydC5kbGwuCj4KPiBJ biBhc2tpbmcgZWxzZXdoZXJlLCBzb21lb25lIGFza2VkIG1lLAo+Cj4gIkJ5IHRoZSB3YXksIHdo eSBkb2Vzbid0IG1pbmd3IGluY2x1ZGUgaXRzIG93biBydW50aW1lIGxpYnJhcmllcz8gSXQKPiBz ZWVtcyB2ZXJ5IGN1cmlvdXMgdGhhdCB0aGV5IHJldXNlIHRoZSBWQyB2ZXJzaW9ucy4gSG93IGlz IHRoYXQKPiBsaWNlbnNlZD8gTWVhbndoaWxlLCB0aGVpciBub3QgZ2l2aW5nIHlvdSBzb3VyY2Ug Y29kZSBmb3IgdGhlCj4gbGlicmFyaWVzIHdpbGwgbWFrZSBkZWJnZ2luZyBjZXJ0YWluIGNsYXNz ZXMgb2YgcHJvYmxlbXMgcXVpdGUgZGlmZmljdWx0LiIKPgo+IENvdWxkIHlvdSBhZGRyZXNzIHRo YXQgcXVlc3Rpb24uCj4KPiBUaGFua3MKPgo+IFNoYWRvdzI1MzEKCgpZb3UgYXBwZWFyIHRvIGJl IGNvbmZ1c2VkIGFzIHRvIHdoYXQgTWluR1cgaXMuIEkgc3VnZ2VzdCB5b3UgcmVhZCB0aGUgZmly c3QKcGFyYWdyYXBoIG9uIGh0dHA6Ly93d3cubWluZ3cub3JnLgoKTWluR1cgZG9lcyBub3QgY29u dGFpbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiBhIEMgcnVudGltZSwgaXQgaXMgaW50ZW5kZWQgdG8K ZW5hYmxlIHBlb3BsZSB0byB1c2UgdGhlIG5hdGl2ZSB3aW5kb3dzIGltcGxlbWVudGF0aW9uLgoK LUQK |
From: Shadow2531 <sha...@tb...> - 2005-10-19 17:18:56
|
Daniel Atallah wrote: > You appear to be confused as to what MinGW is. I suggest you read the first > paragraph on http://www.mingw.org. > > MinGW does not contain an implementation of a C runtime, it is intended to > enable people to use the native windows implementation. > > -D Thanks Shadow2531 |
From: Tor L. <tm...@ik...> - 2005-10-19 15:38:15
|
Shadow2531 writes: > "By the way, why doesn't mingw include its own runtime libraries? Because the explicit purpose of mingw (I hope) is to be mostly compatible with MSVC6 (as long as just C code is concerned), and use the same C runtime. If mingw used its own runtime, mingw-built code couldn't in general be reliably called from MSVC6-compiled code, and vice versa. (For instance things like file descriptors and thus the FILE structs would be completely incompatible.) This would make mingw much less useful for people who want to distribute libraries that can be used both from mingw- and MSVC6-compiled code. Of course, newer MSVC versions (7, 8, .NET, 2003, 2005, etc) don't really support building code against msvcrt.dll any longer, so the above is getting less and less relevant, sigh. Although it does seem that quite many are hanging on to good'old MSVC6. What would really rock now would be for somebody to produce a suitably licensed (MIT or X11-style license) Open Source C runtime for both mingw and MSVC(6,7,8), and then that most developers/distributors of Open Source software for Win32 *and* Win64 would be persuaded to use it. Any volunteers...? One hard thing in such an effort would be to avoid the temptation of reinventing half of Cygwin, i.e. adding too much POSIXness. > It seems very curious that they reuse the VC versions. How is that > licensed? msvcrt.dll is bundled with the operating system. > Meanwhile, their not giving you source code for the libraries will > make debgging certain classes of problems quite difficult." You get the source for (some version of) msvcrt with the Platform SDK. It is also not hard to find copies (leaked by mistake?) on the web. --tml |
From: Shadow2531 <sha...@tb...> - 2005-10-19 17:19:17
|
Tor Lillqvist wrote: > Shadow2531 writes: > > "By the way, why doesn't mingw include its own runtime libraries? > > Because the explicit purpose of mingw (I hope) is to be mostly > compatible with MSVC6 (as long as just C code is concerned), and use > the same C runtime. If mingw used its own runtime, mingw-built code > couldn't in general be reliably called from MSVC6-compiled code, and > vice versa. (For instance things like file descriptors and thus the > FILE structs would be completely incompatible.) This would make mingw > much less useful for people who want to distribute libraries that can > be used both from mingw- and MSVC6-compiled code. > > Of course, newer MSVC versions (7, 8, .NET, 2003, 2005, etc) don't > really support building code against msvcrt.dll any longer, so the > above is getting less and less relevant, sigh. Although it does seem > that quite many are hanging on to good'old MSVC6. > > What would really rock now would be for somebody to produce a suitably > licensed (MIT or X11-style license) Open Source C runtime for both > mingw and MSVC(6,7,8), and then that most developers/distributors of > Open Source software for Win32 *and* Win64 would be persuaded to use > it. Any volunteers...? One hard thing in such an effort would be to > avoid the temptation of reinventing half of Cygwin, i.e. adding too > much POSIXness. > > > It seems very curious that they reuse the VC versions. How is that > > licensed? > > msvcrt.dll is bundled with the operating system. > > > Meanwhile, their not giving you source code for the libraries will > > make debgging certain classes of problems quite difficult." > > You get the source for (some version of) msvcrt with the Platform > SDK. It is also not hard to find copies (leaked by mistake?) on the > web. > > --tml Thanks |
From: amores p. <lif...@ho...> - 2005-10-20 01:06:10
|
>> >> > Meanwhile, their not giving you source code for the libraries will >> > make debgging certain classes of problems quite difficult." >> That problem extends beyond just the libraries to all system calls on Windows, doesn't it? I mean, don't you have to accept a lot of uncertainty and black box experiments as a nature of working on closed source & proprietary Windows platforms? Cordially, Perry |
From: Greg C. <chi...@co...> - 2005-10-17 21:45:17
|
On 2005-10-17 21:10 UTC, Shadow2531 wrote: > Is free() implemented differently with mingw compared to other compilers > like msvc++. (mingw 3.4.2 specifically) > > stdlib.h just imports it from libmsvcrt.a right? Or, does it import it > directly from msvcrt.dll on my WinXP sp2 system? AFAICT, MinGW just uses the msvcrt.dll implementation of free(), through import library 'libmsvcrt.a'. > Where or how can I see exactly what free in libmsvcrt.a is doing? As > much info as possible would be appreciated. I guess you'd have to purchase the source from ms. > Since you'll probably want to know why I want to know about free(); I'm > investigating a quirky effect that calling free(NULL) has on the Windows > low-memory message popup. Calling free(NULL) makes the popup disappear > instantly. It's a pain trying to explain what I'm talking about, so I > would rather focus on how free() is coded than the quirk. Perhaps any call to free(), even with a null argument, causes some sort of memory compaction to be attempted in this case. I'm afraid there's not much we can do here except focus on the quirk or on the underlying cause. Maybe some msvc website or newsgroup archives would explain how free() is implemented. |
From: Shadow2531 <sha...@tb...> - 2005-10-18 00:50:23
|
Greg Chicares wrote: >> Since you'll probably want to know why I want to know about free(); I'm >> investigating a quirky effect that calling free(NULL) has on the Windows >> low-memory message popup. Calling free(NULL) makes the popup disappear >> instantly. It's a pain trying to explain what I'm talking about, so I >> would rather focus on how free() is coded than the quirk. > > Perhaps any call to free(), even with a null argument, causes > some sort of memory compaction to be attempted in this case. > I'm afraid there's not much we can do here except focus on the > quirk or on the underlying cause. Maybe some msvc website or > newsgroup archives would explain how free() is implemented. Thanks. It's *so* hard to reproduce, but thanks. I'll look into it. Shadow2531 |
From: Brian D. <br...@de...> - 2005-10-17 22:46:07
|
Shadow2531 wrote: > Is free() implemented differently with mingw compared to other > compilers like msvc++. (mingw 3.4.2 specifically) No. > stdlib.h just imports it from libmsvcrt.a right? Or, does it import it > directly from msvcrt.dll on my WinXP sp2 system? stdlib.h doesn't import anything, it just declares the function. > Where or how can I see exactly what free in libmsvcrt.a is doing? As > much info as possible would be appreciated. libmsvcrt.a is an import library for msvcrt.dll - it contains no code. It's really just a convenience used for linking. > I'm investigating a quirky effect that calling free(NULL) has on the > Windows low-memory message popup. Calling free(NULL) makes the popup > disappear instantly. It's a pain trying to explain what I'm talking > about, so I would rather focus on how free() is coded than the quirk. The MS docs for free(): "The free function deallocates a memory block (memblock) that was previously allocated by a call to calloc, malloc, or realloc. The number of freed bytes is equivalent to the number of bytes requested when the block was allocated (or reallocated, in the case of realloc). If memblock is NULL, the pointer is ignored and free immediately returns. Attempting to free an invalid pointer (a pointer to a memory block that was not allocated by calloc, malloc, or realloc) may affect subsequent allocation requests and cause errors." According to that, free(NULL) should be a no-op. You'd have to obtain the source to msvcrt.dll to know for sure, though. Brian |
From: Shadow2531 <sha...@tb...> - 2005-10-18 00:52:29
|
Brian Dessent wrote: > Shadow2531 wrote: >> Where or how can I see exactly what free in libmsvcrt.a is doing? As >> much info as possible would be appreciated. > > > libmsvcrt.a is an import library for msvcrt.dll - it contains no code. > It's really just a convenience used for linking. Thanks > The MS docs for free(): > > "The free function deallocates a memory block (memblock) that was > previously allocated by a call to calloc, malloc, or realloc. The number > of freed bytes is equivalent to the number of bytes requested when the > block was allocated (or reallocated, in the case of realloc). If > memblock is NULL, the pointer is ignored and free immediately returns. > Attempting to free an invalid pointer (a pointer to a memory block that > was not allocated by calloc, malloc, or realloc) may affect subsequent > allocation requests and cause errors." > > According to that, free(NULL) should be a no-op. You'd have to obtain > the source to msvcrt.dll to know for sure, though. > > Brian O.K. Thanks. I'm convinced frees() implmented the same. Shadow2531 |
From: amores p. <lif...@ho...> - 2005-10-18 02:15:02
|
>From: Shadow2531 >Subject: Re: [Mingw-users] free() - how is it implemented in mingw? >Date: Mon, 17 Oct 2005 20:52:59 -0400 >> >>According to that, free(NULL) should be a no-op. You'd have to obtain >>the source to msvcrt.dll to know for sure, though. >> >>Brian > >O.K. Thanks. I'm convinced frees() implmented the same. > >Shadow2531 > In the msvctrl code I've seen, there is an if test and an immediate return if the input is NULL. Cordially, Perry |
From: Brian H. <bh...@lu...> - 2007-08-31 01:51:47
|
Can anyone shed some light on this? On an older version of mingw/msys the build did not seem to do this. Warning: .drectve `-defaultlib:OLDNAMES ' unrecognized Cannot export ??_C@_02DILL@?$CFs?$AA@: symbol not found Cannot export ??_C@_08PNBE@?$CFs?5?$CFd?5?$CFd?$AA@: symbol not found Cannot export ??_C@_09GECL@ppmon?4exe?$AA@: symbol not found Cannot export ??_C@_0BA@JOCO@?2?2?4?2KeyDongle_0?$AA@: symbol not found Cannot export ??_C@_0BB@GJGA@Driver?5not?5found?$AA@: symbol not found Cannot export ??_C@_0BB@PDPJ@?2?2?4?2PARCLASS?4VXD?$AA@: symbol not found Cannot export ??_C@_0O@FBNE@?2?2?4?2PARCLASS0?$AA@: symbol not found collect2: ld returned 1 exit status |
From: Brian H. <bh...@lu...> - 2007-08-31 02:02:57
|
By removing the trailing / from -I../ it finds the headers fine. Interesting that this did not seem to be a problem before. At 06:26 PM 8/30/2007, Brian Hawley wrote: >I've just installed the latest mingw and msys 'current' packages. > >gcc is actually running in > >v:/users/bhawley/.../Libraries/base > >in v:/users/bhawley/.../Libraries is a file called project.h > >for some reason, gcc is not able to find it even though -I../ is specified >on the command line. i checked the permissions and i can access the file. > >any suggestions on how to resolve this would be appreciated. > >gcc -DARCH=generic-i386-winxp -DVERSION_STRING='"base 2.1.0.4 ARCH: >generic-i386-winxp libs: wsock32 iberty msvcrt Built: Thu Aug 30 >18:21:46 PDT 2007 Copyright(C) 2004 Luminex Software, Inc. All Rights >Reserved."' -I./ -I../ -I../generic-i386-winxp/ >-I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4//include >-I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/ >-I/home/engr/support/site/1.7 >-I/home/engr/support/site/1.7/generic-i386-winxp -I/usr/local/include >-I/home/engr/support/generic-i386-winxp/w32compat/pthread/include -c >lsirand.c -o >/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/lsirand.o >In file included from lsirand.c:75: >v:/support/site/1.7/site.h:147:21: project.h: No such file or directory > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >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: Brian H. <bh...@lu...> - 2007-08-31 02:03:54
|
By removing a .OBJ which is supplied by a third party, the build completes okay. I'm still curious why I can't have the .OBJ as part of the build. At 06:51 PM 8/30/2007, Brian Hawley wrote: >Can anyone shed some light on this? On an older version of mingw/msys the >build did not seem to do this. > >Warning: .drectve `-defaultlib:OLDNAMES ' unrecognized >Cannot export ??_C@_02DILL@?$CFs?$AA@: symbol not found >Cannot export ??_C@_08PNBE@?$CFs?5?$CFd?5?$CFd?$AA@: symbol not found >Cannot export ??_C@_09GECL@ppmon?4exe?$AA@: symbol not found >Cannot export ??_C@_0BA@JOCO@?2?2?4?2KeyDongle_0?$AA@: symbol not found >Cannot export ??_C@_0BB@GJGA@Driver?5not?5found?$AA@: symbol not found >Cannot export ??_C@_0BB@PDPJ@?2?2?4?2PARCLASS?4VXD?$AA@: symbol not found >Cannot export ??_C@_0O@FBNE@?2?2?4?2PARCLASS0?$AA@: symbol not found >collect2: ld returned 1 exit status > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >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: Brian D. <br...@de...> - 2007-08-31 02:28:48
|
Brian Hawley wrote: > By removing a .OBJ which is supplied by a third party, the build completes > okay. > > I'm still curious why I can't have the .OBJ as part of the build. gcc and MSVC are compatible at the C ABI level only. Not C++. Those are C++ symbols. Brian |
From: Brian H. <bh...@lu...> - 2007-08-31 03:01:48
|
hmmm....i built this same chain with the same file on an older version of mingw about 2 years ago. I don't believe that file is a c++ file. At 07:28 PM 8/30/2007, Brian Dessent wrote: >Brian Hawley wrote: > > > By removing a .OBJ which is supplied by a third party, the build completes > > okay. > > > > I'm still curious why I can't have the .OBJ as part of the build. > >gcc and MSVC are compatible at the C ABI level only. Not C++. Those >are C++ symbols. > >Brian > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >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: NightStrike <nig...@gm...> - 2007-08-31 06:11:05
|
You could d/l an older version of mingw and try again just to be sure. On 8/30/07, Brian Hawley <bh...@lu...> wrote: > > hmmm....i built this same chain with the same file on an older version of > mingw about 2 years ago. > > I don't believe that file is a c++ file. > > At 07:28 PM 8/30/2007, Brian Dessent wrote: > >Brian Hawley wrote: > > > > > By removing a .OBJ which is supplied by a third party, the build completes > > > okay. > > > > > > I'm still curious why I can't have the .OBJ as part of the build. > > > >gcc and MSVC are compatible at the C ABI level only. Not C++. Those > >are C++ symbols. > > > >Brian > > > >------------------------------------------------------------------------- > >This SF.net email is sponsored by: Splunk Inc. > >Still grepping through log files to find problems? Stop. > >Now Search log events and configuration files using AJAX and a browser. > >Download your FREE copy of Splunk now >> http://get.splunk.com/ > >_______________________________________________ > >MinGW-users mailing list > >Min...@li... > > > >You may change your MinGW Account Options or unsubscribe at: > >https://lists.sourceforge.net/lists/listinfo/mingw-users > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > 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: Brian D. <br...@de...> - 2005-10-19 19:45:40
|
Shadow2531 wrote: > "By the way, why doesn't mingw include its own runtime libraries? It Because there is already a C library available on the platform. MSVCRT is a system component that is guaranteed to exist on any windows machine. > seems very curious that they reuse the VC versions. How is that > licensed? The C library isn't licensed by mingw per se, because nobody is distributing MSVCRT.DLL. All mingw is doing is calling the routines, just like 99.99% of all other windows programs. If there were licensing pitfalls with MSVCRT there would be a lot more problems than just mingw because almost every win32 app out there - commercial, freeware, shareware, open source - links against these routines. > Meanwhile, their not giving you source code for the > libraries will make debgging certain classes of problems quite difficult." Reimplmenting a C library would be an enourmous amount of work. It would also go against the notion of mingw being a "native" compiler, because native windows programs use MSVCRT. It would also bloat all compiled programs in that you would have to distribute this C runtime as a seperate DLL with your app, which would fail to run without it. If that's what you want then you can use Cygwin, which does provide its own C runtime that has complete GPL source that you can poke at. But as far as I can tell, most people using mingw are doing so precisely because they don't want some runtime hanging around that they have to distribute. Brian |
From: Tor L. <tm...@ik...> - 2005-10-20 00:11:57
|
Brian Dessent writes: > nobody is distributing MSVCRT.DLL. All mingw is doing is calling > the routines, just like 99.99% of all other windows programs. Aren't you exaggerating? Aren't quite many new apps presumably using mscr70.dll, msvcr71.dll or even msvcr80.dll, as those are what Microsoft's newer compilers make code use? > you can use Cygwin, which does provide its own C runtime that has > complete GPL source that you can poke at. (Which means apps running on top of Cygwin must also be licensed using the GPL if distributed, but I assume you know that.) --tml |
From: Brian D. <br...@de...> - 2005-10-20 00:27:11
|
Tor Lillqvist wrote: > > Brian Dessent writes: > > nobody is distributing MSVCRT.DLL. All mingw is doing is calling > > the routines, just like 99.99% of all other windows programs. > > Aren't you exaggerating? Aren't quite many new apps presumably using > mscr70.dll, msvcr71.dll or even msvcr80.dll, as those are what > Microsoft's newer compilers make code use? I was lumping together all the various versions of the MSVCRT in that statement. I should have said "99.99% of all windows programs link to (some version of) the MSVCRT." I don't know what the status of msvcr70.dll and msvcr71.dll are with respect to them being defined as system components that are guaranteed to be present. I have both a win2k and a win98 that are almost completely stock with very few programs installed and they both have msvcr71.dll. But, those could have come from one of those few programs I installed. Brian |
From: Brian H. <bh...@lu...> - 2007-08-31 01:26:07
|
I've just installed the latest mingw and msys 'current' packages. gcc is actually running in v:/users/bhawley/.../Libraries/base in v:/users/bhawley/.../Libraries is a file called project.h for some reason, gcc is not able to find it even though -I../ is specified on the command line. i checked the permissions and i can access the file. any suggestions on how to resolve this would be appreciated. gcc -DARCH=generic-i386-winxp -DVERSION_STRING='"base 2.1.0.4 ARCH: generic-i386-winxp libs: wsock32 iberty msvcrt Built: Thu Aug 30 18:21:46 PDT 2007 Copyright(C) 2004 Luminex Software, Inc. All Rights Reserved."' -I./ -I../ -I../generic-i386-winxp/ -I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4//include -I/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/ -I/home/engr/support/site/1.7 -I/home/engr/support/site/1.7/generic-i386-winxp -I/usr/local/include -I/home/engr/support/generic-i386-winxp/w32compat/pthread/include -c lsirand.c -o /home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.1.0.4/base/lsirand.o In file included from lsirand.c:75: v:/support/site/1.7/site.h:147:21: project.h: No such file or directory |
From: Tuomo L. <dj...@ik...> - 2007-08-31 13:23:37
|
Brian Hawley wrote: [...] Umm.. The thread "[Mingw-users] free() - how is it implemented in mingw?" now also contains messages from no less than *two* completely nonrelated subjects, thanks to you. I read my messages using a threaded view. The threads are determined based on either of the following reasons: 1) "References" header. The message I responded to references message id "<435...@tb...>", which, apparently by sheer accident, is the id of the first post of the aforementioned thread. 2) "Subject" header. You managed to change the subject, a worthy accomplishment in itself. However, you did not scrub the reference out of the message, so now your messages, as well as all the replies to them, seem to be replies to an unrelated thread. This not only affects me, but anyone reading the list archives on the web. I would appreciate if in future you would get rid of references to other messages when starting a new thread. The easiest way to do that is to *not* *reply* to messages, but write a completely new one instead. If it is a question along the lines of not being able to remember the mailing list address, I suggest you either take a look at the address book functionality of your e-mail client or familiarize yourself with the art of copy-paste (possibly using the functionality of your windowing system or even pen and paper). Thank you, -- Tuomo ... There is much Obi-Wan did not tell you |