Date: Fri, 21 Oct 2005 00:04:23 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 637 ************************************************** Thursday 20 October 2005 Number 637 ************************************************** Subjects for today 1 Re: GNU Patch v2.54 : John Poltorak 2 Re: GNU Patch v2.54 : Stefan.Neis at t-online.de 3 Re: GNU Patch v2.54 : John Poltorak 4 Re: GNU Patch v2.54 : Stefan.Neis at t-online.de 5 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 6 Re: GNU Patch v2.54 : Dave Yeo" 7 Re: GNU Patch v2.54 : John Poltorak 8 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 9 Re: gdb for gcc 3.3.2 and 3.3.5? : Jon Saxton 10 Re: gdb for gcc 3.3.2 and 3.3.5? : Sebastian Wittmeier 11 Re: GNU Patch v2.54 : Andrew MacIntyre **= Email 1 ==========================** Date: Wed, 19 Oct 2005 14:58:36 +0100 From: John Poltorak Subject: Re: GNU Patch v2.54 On Tue, Oct 18, 2005 at 11:36:53PM +0200, Andreas Buening wrote: > John Poltorak wrote: > > > Any chance of uploading your port somewhere? > > I've uploaded it temporarily to > http://unix.os2site.com/sw/pub/source/autoconf/patch-2_5_4.zip > and > http://unix.os2site.com/sw/pub/source/autoconf/patch-2_5_4-bin.zip > > It's possible that I took the (tiny) patches from somewhere else > (maybe except for Makefile.in or so) but I don't remember. Many thanks for this. It's always good to see OS/2 versions up to the same level as those for other platforms. A couple of points which come to mind after trying it... The source file includes a zip file of the diffs along with the diffs themselves. When I tried building it, I had problems running configure when the recommended LDFLAGS were set, those being LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" When those settings were included I got the following configure errors - (from config.log):- configure:1756: gcc -v &5 Using builtin specs. gcc version 2.8.1 configure:1759: $? = 0 configure:1761: gcc -V &5 gcc: argument to `-V' is missing configure:1764: $? = 1 configure:1787: checking for C compiler default output file name configure:1790: gcc -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio conftest.c >&5 G:\UX2BS\EMX\BIN\ld.exe: unrecognized option `-O' Usage: G:\UX2BS\EMX\BIN\ld.exe [-d] [-dc] [-dp] [-e symbol] [-l lib] [-n] [-noinhibit-exec] [-nostdlib] [-o file] [-r] [-s] [-t] [-u symbol] [-x] [-y symbol] [-z] [-A file] [-Bstatic] [-D size] [-L libdir] [-M] [-N] [-S] [-T[{text,data}] addr] [-V prefix] [-X] [file...] configure:1793: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:1831: error: C compiler cannot create executables See `config.log' for more details. Your diffs for patch v2.5.4 are slightly different from those provided by Jun SAWATAISHI who also did a port, although I can't tell how signifacant those differences are. Would you be able to check? > > Bye, > Andreas -- John **= Email 2 ==========================** Date: Wed, 19 Oct 2005 17:08:34 +0100 From: Stefan.Neis at t-online.de Subject: Re: GNU Patch v2.54 Hi, > LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" Those seem a bit nonsensical to me. IIRC, that should be _either_ LDFLAGS="-Zomf -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" _or_ LDFLAGS="-Zcrtdll" i.e. those "Zlinker" options only make sense for OMF builds, AFAIK. Regards, Stefan **= Email 3 ==========================** Date: Wed, 19 Oct 2005 16:37:51 +0100 From: John Poltorak Subject: Re: GNU Patch v2.54 On Wed, Oct 19, 2005 at 05:08:34PM +0100, Stefan.Neis at t-online.de wrote: > Hi, > > > LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" > > Those seem a bit nonsensical to me. I've used the same flags for other apps and they have worked. > IIRC, that should be _either_ > LDFLAGS="-Zomf -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" When using this value I get the following error:- gcc -o patch.exe -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zomf -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio addext.o argmatch.o backupfile.o basename.o error.o inp.o maketime.o partime.o patch.o pch.o quotearg.o quotesys.o util.o version.o xmalloc.o addext.o : fatal error L1101: invalid object module Object file offset: 1 Record type: 07 make: *** [patch.exe] Error 1 > _or_ > LDFLAGS="-Zcrtdll" > i.e. those "Zlinker" options only make sense for OMF builds, AFAIK. I get completely lost with various *FLAGS and am content to try and use what people suggest. > Regards, > Stefan > > -- John **= Email 4 ==========================** Date: Wed, 19 Oct 2005 18:17:40 +0100 From: Stefan.Neis at t-online.de Subject: Re: GNU Patch v2.54 Hi again, > > IIRC, that should be _either_ > > LDFLAGS="-Zomf -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" > > When using this value I get the following error:- > > > gcc -o patch.exe -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zomf -Zcrtdll -Zlinker > /exepack:2 -Zlinker /pm:vio addext.o argmatch.o backupfile.o basename.o > error.o inp.o maketime.o partime.o patch.o pch.o quotearg.o quotesys.o > util.o version.o xmalloc.o > > addext.o : fatal error L1101: invalid object module > Object file offset: 1 Record type: 07 > make: *** [patch.exe] Error 1 So everything seems to be compiled in a.out mode. Then you should rather try my other suggestion: > > _or_ > > LDFLAGS="-Zcrtdll" > > i.e. those "Zlinker" options only make sense for OMF builds, AFAIK. > > > I get completely lost with various *FLAGS and am content to try and use > what people suggest. Yes, me too, that's why I always stayed with a.out for my own usage - it's much less confusing than trying to get things set up for OMF consistently. Regards, Stefan **= Email 5 ==========================** Date: Wed, 19 Oct 2005 15:12:23 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Knut: Thanks for your input. I had already begun to suspect the linker, or perhaps some DLL that it is using. I even went so far as to re-install VAC++ 3.6.5 from the original CDs rather than just using my directory transported from another machine although as I type this message I have not yet applied the CSDs or tested the gcc 3.2.2 builds. No, I am not a fan of gdb but it can be useful when it works. I have to remain familiar with it in case I ever need to debug on UNIX. That has only happened twice - normally my UNIX usage is just to say "dmake". Meanwhile I solved my immediate debugging issue by rebuilding everything with gcc 3.2.1 and using gdb on that. One line doth a program break. The pointer to the Mozilla development page was extremely helpful, thanks for that. I'll post results when I have them, Knut St. Osmundsen wrote: > Jon Saxton wrote: > >> So close! >> >> I rebuilt the libraries as .a files in a.out format. Now gcc -Zomf >> -o gives various errors >> depending on the specific command line. Sometimes it just spaces up >> about ten lines and exits without generating an exe or any message. >> Other times I get LNK1081 errors (out of space for ) or "No >> space for NB04" whatever that might be. Very frustrating. > > > I've never ever seen that error. But at you using the right linker? > (see below) > >> I may end up moving the code to a UNIX system and debugging there. >> Might be easier. > > > If you're a gdb fan, it will sure be easier. :-) > >> >> Jon Saxton wrote: >> >>> Knut: >>> >>> Thanks also for your input. I have made much progress but I am one >>> small step from having it work properly. >>> >>> I had to tweak a lot of my environment settings and my dmake >>> configuration files to run emxomfar instead of ar, to let me see >>> ilink.exe, idebug.exe and the DLLs and data files that those programs >>> need. I set emxomf_linker and exmomfld_type even though the default is >>> set for VAC++ 3.6.5 which is what I have installed. >> > > You want to use the ilink v5 from the mozilla build page. You do not > ever want to you ilink from VAC 3.6.5, it's buggy and likely to blow > up at the smallest provocation. the only other usable ilink version is > the one from VAC308. > >>> I rebuilt my own (static) libraries by compiling with -Zomf and using >>> emxomfar to assemble a .lib file. I thought that I had the >>> libraries in >>> the right format so I put -Xlibrary -Zno-autoconv in the gcc linker >>> invocation command to stop automatic conversion of my libraries from >>> a.out format to omf format. >>> >>> The current stumbling block is a message which pops out of the link ... >>> >>> wealkd:: ..\lib\os2\simpl.lib: error: Invalid library format or read >>> error >>> emxomfld: weak prelinker failed. (rc=-1) >>> >>> I have the impression that emxomfld really prefers a.out format. :-) >> > (No, it preferes OMF. The automatic a.out conversion is only there for > making building debuggable code simpler.) > >>> I'll try rebuilding my libraries the old way but it would be really >>> annoying to have to compile with -Zomf for most code but without -Zomf >>> for stuff that is going into a library. I expect that isn't going >>> to be >>> necessary and that it is probably just a matter of understanding this >>> stuff much better. >>> >>> >>> >>> Knut St. Osmundsen wrote: >>> >>>> >>>> >>>> Jon Saxton wrote: >>>> >>>>> Thanks, Dave for your reply. >>>>> >>>>> I had just come to the conclusion that the OMF route is >>>>> mandatory. That raises some more issues because I cannot find any >>>>> documentation on the omf switches. I looked in the GCC "docs" >>>>> folder and tried various gcc --help options with no success. >>>>> >>>>> I have yet to look in the emx docs. That I'll do shortly. >>>>> >>>>> Can I still use gcc as a front end to the linker or do I have to >>>>> change my makefiles to invoke ILINK? >>>> >>>> >>>> >>>> >>>> >>>> gcc / g++ -Zomf will invoke ilink for you (using emxomfld). >>>> >>>> emxomfld will before invoking ilink to a prelink step in which it >>>> automatically converts any aout objects/libs to omf objects/libs. >>>> Thus it is only required to add -Zomf to the linking stage. >>>> >>>> If you cannot distiguish between the linking and the compiling, you >>>> must make sure you're using emxomfar and not ar as librarian. The >>>> ilink and emxomfld cannot make use of OMF objects in a library >>>> created with ar. >>>> >>>> Kind Regards, >>>> knut >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> > > > > **= Email 6 ==========================** Date: Wed, 19 Oct 2005 20:55:09 -0700 (PDT) From: "Dave Yeo" Subject: Re: GNU Patch v2.54 On Wed, 19 Oct 2005 16:37:51 +0100, John Poltorak wrote: >On Wed, Oct 19, 2005 at 05:08:34PM +0100, Stefan.Neis at t-online.de wrote: >> Hi, >> >> > LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" >> >> Those seem a bit nonsensical to me. > >I've used the same flags for other apps and they have worked. > >> IIRC, that should be _either_ >> LDFLAGS="-Zomf -Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" > >When using this value I get the following error:- > > >gcc -o patch.exe -O2 -s -Zmt -D__ST_MT_ERRNO__ -Zomf -Zcrtdll -Zlinker >/exepack:2 -Zlinker /pm:vio addext.o argmatch.o backupfile.o basename.o >error.o inp.o maketime.o partime.o patch.o pch.o quotearg.o quotesys.o >util.o version.o xmalloc.o > >addext.o : fatal error L1101: invalid object module > Object file offset: 1 Record type: 07 >make: *** [patch.exe] Error 1 > The object files also have to built with -Zomf (at least with EMX). This will cause the object files to have the suffix OBJ instead of O (at least with GCC 2.8.1) which IIRC can be corrected by -o Much easier to just build a.outs and just use GCC for linking > >> _or_ >> LDFLAGS="-Zcrtdll" >> i.e. those "Zlinker" options only make sense for OMF builds, AFAIK. Dave **= Email 7 ==========================** Date: Thu, 20 Oct 2005 09:54:47 +0100 From: John Poltorak Subject: Re: GNU Patch v2.54 On Wed, Oct 19, 2005 at 02:58:36PM +0100, John Poltorak wrote: > When I tried building it, I had problems running configure when the > recommended LDFLAGS were set, those being > > LDFLAGS="-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio" Apologies for wasting time on this - it was my fault. I hadn't actually set *FLAGS as I had thought. Patch does build properly using these suggested variables CFLAGS='-Zomf -O2 -s -Zmt -D__ST_MT_ERRNO__' LDFLAGS='-Zcrtdll -Zlinker /exepack:2 -Zlinker /pm:vio' The only thing I can't figure out is why Andreas' patch.exe is 50k and mine is 65k. -- John **= Email 8 ==========================** Date: Thu, 20 Oct 2005 08:32:47 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Most of the problems went away with the new VAC++ install and, in particular, with the updated ILink. The LNK1081 error "No space for NB04" persists. The problem seems to be that I am building on a drive with almost 70 Gb of free space. When I ran on a drive with a few hundred Mb free then everything worked. Switching to a new drive isn't really an option since my sources have to be visible on OS/2 and Windows (and soon on Linux). They reside on a Windows directory which is seen as a shared directory on OS/2 under Virtual PC. I thought there was a gizmo which intercepted the call to get the free space on a drive and reported a fake number but I couldn't find it on a quick search of Hobbes. There is spacehog but that seems to fill the drive with temporary files - something which is not an option on a shared disk. I wish life would be simple, sometimes. Jon Saxton wrote: > Knut: > > Thanks for your input. I had already begun to suspect the linker, or > perhaps some DLL that it is using. I even went so far as to > re-install VAC++ 3.6.5 from the original CDs rather than just using my > directory transported from another machine although as I type this > message I have not yet applied the CSDs or tested the gcc 3.2.2 builds. > > No, I am not a fan of gdb but it can be useful when it works. I have > to remain familiar with it in case I ever need to debug on UNIX. That > has only happened twice - normally my UNIX usage is just to say > "dmake". Meanwhile I solved my immediate debugging issue by > rebuilding everything with gcc 3.2.1 and using gdb on that. One line > doth a program break. > > The pointer to the Mozilla development page was extremely helpful, > thanks for that. I'll post results when I have them, > > > Knut St. Osmundsen wrote: > >> Jon Saxton wrote: >> >>> So close! >>> >>> I rebuilt the libraries as .a files in a.out format. Now gcc -Zomf >>> -o gives various errors >>> depending on the specific command line. Sometimes it just spaces up >>> about ten lines and exits without generating an exe or any message. >>> Other times I get LNK1081 errors (out of space for ) or "No >>> space for NB04" whatever that might be. Very frustrating. >> >> >> >> I've never ever seen that error. But at you using the right linker? >> (see below) >> >>> I may end up moving the code to a UNIX system and debugging there. >>> Might be easier. >> >> >> >> If you're a gdb fan, it will sure be easier. :-) >> >>> >>> Jon Saxton wrote: >>> >>>> Knut: >>>> >>>> Thanks also for your input. I have made much progress but I am one >>>> small step from having it work properly. >>>> >>>> I had to tweak a lot of my environment settings and my dmake >>>> configuration files to run emxomfar instead of ar, to let me see >>>> ilink.exe, idebug.exe and the DLLs and data files that those programs >>>> need. I set emxomf_linker and exmomfld_type even though the >>>> default is >>>> set for VAC++ 3.6.5 which is what I have installed. >>> >>> >> >> You want to use the ilink v5 from the mozilla build page. You do not >> ever want to you ilink from VAC 3.6.5, it's buggy and likely to blow >> up at the smallest provocation. the only other usable ilink version >> is the one from VAC308. >> >>>> I rebuilt my own (static) libraries by compiling with -Zomf and using >>>> emxomfar to assemble a .lib file. I thought that I had the >>>> libraries in >>>> the right format so I put -Xlibrary -Zno-autoconv in the gcc linker >>>> invocation command to stop automatic conversion of my libraries from >>>> a.out format to omf format. >>>> >>>> The current stumbling block is a message which pops out of the link >>>> ... >>>> >>>> wealkd:: ..\lib\os2\simpl.lib: error: Invalid library format or >>>> read error >>>> emxomfld: weak prelinker failed. (rc=-1) >>>> >>>> I have the impression that emxomfld really prefers a.out format. :-) >>> >>> >> (No, it preferes OMF. The automatic a.out conversion is only there >> for making building debuggable code simpler.) >> >>>> I'll try rebuilding my libraries the old way but it would be really >>>> annoying to have to compile with -Zomf for most code but without -Zomf >>>> for stuff that is going into a library. I expect that isn't going >>>> to be >>>> necessary and that it is probably just a matter of understanding this >>>> stuff much better. >>>> >>>> >>>> >>>> Knut St. Osmundsen wrote: >>>> >>>>> >>>>> >>>>> Jon Saxton wrote: >>>>> >>>>>> Thanks, Dave for your reply. >>>>>> >>>>>> I had just come to the conclusion that the OMF route is >>>>>> mandatory. That raises some more issues because I cannot find >>>>>> any documentation on the omf switches. I looked in the GCC >>>>>> "docs" folder and tried various gcc --help options with no success. >>>>>> >>>>>> I have yet to look in the emx docs. That I'll do shortly. >>>>>> >>>>>> Can I still use gcc as a front end to the linker or do I have to >>>>>> change my makefiles to invoke ILINK? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> gcc / g++ -Zomf will invoke ilink for you (using emxomfld). >>>>> >>>>> emxomfld will before invoking ilink to a prelink step in which it >>>>> automatically converts any aout objects/libs to omf objects/libs. >>>>> Thus it is only required to add -Zomf to the linking stage. >>>>> >>>>> If you cannot distiguish between the linking and the compiling, >>>>> you must make sure you're using emxomfar and not ar as librarian. >>>>> The ilink and emxomfld cannot make use of OMF objects in a library >>>>> created with ar. >>>>> >>>>> Kind Regards, >>>>> knut >>>>> **= Email 9 ==========================** Date: Thu, 20 Oct 2005 08:31:58 -0400 From: Jon Saxton Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Most of the problems went away with the new VAC++ install and, in particular, with the updated ILink. The LNK1081 error "No space for NB04" persists. The problem seems to be that I am building on a drive with almost 70 Gb of free space. When I ran on a drive with a few hundred Mb free then everything worked. Switching to a new drive isn't really an option since my sources have to be visible on OS/2 and Windows (and soon on Linux). They reside on a Windows directory which is seen as a shared directory on OS/2 under Virtual PC. I thought there was a gizmo which intercepted the call to get the free space on a drive and reported a fake number but I couldn't find it on a quick search of Hobbes. There is spacehog but that seems to fill the drive with temporary files - something which is not an option on a shared disk. I wish life would be simple, sometimes. Jon Saxton wrote: > Knut: > > Thanks for your input. I had already begun to suspect the linker, or > perhaps some DLL that it is using. I even went so far as to > re-install VAC++ 3.6.5 from the original CDs rather than just using my > directory transported from another machine although as I type this > message I have not yet applied the CSDs or tested the gcc 3.2.2 builds. > > No, I am not a fan of gdb but it can be useful when it works. I have > to remain familiar with it in case I ever need to debug on UNIX. That > has only happened twice - normally my UNIX usage is just to say > "dmake". Meanwhile I solved my immediate debugging issue by > rebuilding everything with gcc 3.2.1 and using gdb on that. One line > doth a program break. > > The pointer to the Mozilla development page was extremely helpful, > thanks for that. I'll post results when I have them, > > > Knut St. Osmundsen wrote: > >> Jon Saxton wrote: >> >>> So close! >>> >>> I rebuilt the libraries as .a files in a.out format. Now gcc -Zomf >>> -o gives various errors >>> depending on the specific command line. Sometimes it just spaces up >>> about ten lines and exits without generating an exe or any message. >>> Other times I get LNK1081 errors (out of space for ) or "No >>> space for NB04" whatever that might be. Very frustrating. >> >> >> >> I've never ever seen that error. But at you using the right linker? >> (see below) >> >>> I may end up moving the code to a UNIX system and debugging there. >>> Might be easier. >> >> >> >> If you're a gdb fan, it will sure be easier. :-) >> >>> >>> Jon Saxton wrote: >>> >>>> Knut: >>>> >>>> Thanks also for your input. I have made much progress but I am one >>>> small step from having it work properly. >>>> >>>> I had to tweak a lot of my environment settings and my dmake >>>> configuration files to run emxomfar instead of ar, to let me see >>>> ilink.exe, idebug.exe and the DLLs and data files that those programs >>>> need. I set emxomf_linker and exmomfld_type even though the >>>> default is >>>> set for VAC++ 3.6.5 which is what I have installed. >>> >>> >> >> You want to use the ilink v5 from the mozilla build page. You do not >> ever want to you ilink from VAC 3.6.5, it's buggy and likely to blow >> up at the smallest provocation. the only other usable ilink version >> is the one from VAC308. >> >>>> I rebuilt my own (static) libraries by compiling with -Zomf and using >>>> emxomfar to assemble a .lib file. I thought that I had the >>>> libraries in >>>> the right format so I put -Xlibrary -Zno-autoconv in the gcc linker >>>> invocation command to stop automatic conversion of my libraries from >>>> a.out format to omf format. >>>> >>>> The current stumbling block is a message which pops out of the link >>>> ... >>>> >>>> wealkd:: ..\lib\os2\simpl.lib: error: Invalid library format or >>>> read error >>>> emxomfld: weak prelinker failed. (rc=-1) >>>> >>>> I have the impression that emxomfld really prefers a.out format. :-) >>> >>> >> (No, it preferes OMF. The automatic a.out conversion is only there >> for making building debuggable code simpler.) >> >>>> I'll try rebuilding my libraries the old way but it would be really >>>> annoying to have to compile with -Zomf for most code but without -Zomf >>>> for stuff that is going into a library. I expect that isn't going >>>> to be >>>> necessary and that it is probably just a matter of understanding this >>>> stuff much better. >>>> >>>> >>>> >>>> Knut St. Osmundsen wrote: >>>> >>>>> >>>>> >>>>> Jon Saxton wrote: >>>>> >>>>>> Thanks, Dave for your reply. >>>>>> >>>>>> I had just come to the conclusion that the OMF route is >>>>>> mandatory. That raises some more issues because I cannot find >>>>>> any documentation on the omf switches. I looked in the GCC >>>>>> "docs" folder and tried various gcc --help options with no success. >>>>>> >>>>>> I have yet to look in the emx docs. That I'll do shortly. >>>>>> >>>>>> Can I still use gcc as a front end to the linker or do I have to >>>>>> change my makefiles to invoke ILINK? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> gcc / g++ -Zomf will invoke ilink for you (using emxomfld). >>>>> >>>>> emxomfld will before invoking ilink to a prelink step in which it >>>>> automatically converts any aout objects/libs to omf objects/libs. >>>>> Thus it is only required to add -Zomf to the linking stage. >>>>> >>>>> If you cannot distiguish between the linking and the compiling, >>>>> you must make sure you're using emxomfar and not ar as librarian. >>>>> The ilink and emxomfld cannot make use of OMF objects in a library >>>>> created with ar. >>>>> >>>>> Kind Regards, >>>>> knut >>>>> -- Jon Saxton Shopkeeper, Numismatist-in-training Developer of cross-platform software for UNIX, OS/2 and Windows U.S. Agent for Triton Technologies International Ltd http://www.triton.vg/ **= Email 10 ==========================** Date: Thu, 20 Oct 2005 14:49:39 +0200 From: Sebastian Wittmeier Subject: Re: gdb for gcc 3.3.2 and 3.3.5? Hi Jon, you could use Netdrive. It has an option to mount local file systems and set the free space to an arbitrary value. I don't know how much the performance suffers when compiling. Sebastian Jon Saxton wrote: > Most of the problems went away with the new VAC++ install and, in > particular, with the updated ILink. The LNK1081 error "No space for > NB04" persists. The problem seems to be that I am building on a drive > with almost 70 Gb of free space. When I ran on a drive with a few > hundred Mb free then everything worked. > > Switching to a new drive isn't really an option since my sources have to > be visible on OS/2 and Windows (and soon on Linux). They reside on a > Windows directory which is seen as a shared directory on OS/2 under > Virtual PC. > > I thought there was a gizmo which intercepted the call to get the free > space on a drive and reported a fake number but I couldn't find it on a > quick search of Hobbes. There is spacehog but that seems to fill the > drive with temporary files - something which is not an option on a > shared disk. > > I wish life would be simple, sometimes. **= Email 11 ==========================** Date: Thu, 20 Oct 2005 21:47:37 +1100 From: Andrew MacIntyre Subject: Re: GNU Patch v2.54 John Poltorak wrote: > The only thing I can't figure out is why Andreas' patch.exe is 50k and > mine is 65k. 2 things that come to mind which may help account for some of the differences: - tab / space conversion - Unix vs DOS new lines Cheers, Andrew. ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia