Xref: news2.mv.net comp.os.msdos.djgpp:7547 From: Thomas Demmer Newsgroups: comp.os.msdos.djgpp Subject: Re: problem report Date: Fri, 16 Aug 1996 08:53:07 +0100 Organization: Lehrstuhl fuer Stroemungsmechanik Lines: 81 Message-ID: <321428E3.446B@LSTM.Ruhr-UNI-Bochum.De> References: <3213BF6D AT cpds01 DOT coe DOT ttu DOT edu> NNTP-Posting-Host: bvb.lstm.ruhr-uni-bochum.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Don Bagert DJ-Gateway: from newsgroup comp.os.msdos.djgpp Don Bagert wrote: > > I have been having a problem with using djgpp.env under gnatlink on a Novell > Network server (version 2.15 - yes, I know it's an old version!). When > performing a gnatlink, I receive the following message: > > "f:/lang/gwada/gnat305\bin\ld.exe: cannot open linker script file djgpp.lnk: > No such file or directory (ENOENT)" > > I should also mention that when I installed djgpp and gnat on my hard drive, > I had no problem. Everything is configured the same way on the network > (including no access restrictions on any of the files) except that the drive > and directory are different; however, the path and all environment variables > are properly set. Other attempts (such as using the -gnatlink option on > gnatlink) have me convinced that the problem has to do with the network, and > that files that gnatlink says are not there definitely are. > > Now, I am aware of the following excerpt from djgppfaq.txt: [...] > However, I have talked with our network administrator (who is definitely an > expert on Novell), and he says that the FILES=60 in the autoexec.bat should > also apply to the network drive. We also looked through some documentation > trying to find something like what you describe above, without success. Well what you need is an Novell & djgpp expert, and Texas is probably a nice place;-) Reposting what I wrote a few days ago: stat() in fact has a bug. gcc stats() for 'x:/djgpp/lib/.' to check if the library directory exists. This works fine, if x is a local drive, but fails for network drives. Eli once sent me a patch for that, it is available on ftp://ftp.lstm.ruhr-uni-bochum.de/pub/djgpp/patches/stat.pat I have recompiled gcc with that patch and it works fine. If you really want to have that, I can put it into the same area. A simpler (?!) workaround is to switch from NETX to VLM. If you need help on that, send me a mail. But you will not want to put djgpp on a networked drive. fseek() has a bug, or better a workaround for a bug, that drastically degrades performance on drives that do not benefit from smartdrive and alikes. (Anybody working on that? I need some space on my local drive ;-) So unless you have a 100MBit network, expect linking times for ``hello world'' of some 40 seconds. (It does _not_ crash, just be patient. I ain't) Oh yes, why does gcc stat 'x:/djgpp/lib/.' instead of 'x:/djgpp/lib' ? Well, it comes from UNIX and you can have symbolic links. The dotless test can exist, but might be a link pointing to some nonexisting directory. Or it might be just a plain file, or some pipe or whatever. The first test makes sure that the path leads to an existing directory. Just to show you some gotchas when porting from DOS to UNIX... --- As I wrote, I do have a gcc which runs, and you cannot do anything wrong with typing ``make'' I am still somewhat reluctant to distribute that version. For the fseek() stuff, when I have the time to put djgpp on my network, I'll check the efficiency of ``CACHE BUFFERS = xx'' in the Netware DOS Requester Section. -- Ciao Tom ************************************************************* * Thomas Demmer * * Lehrstuhl fuer Stroemungsmechanik * * Ruhr-Uni-Bochum * * Universitaetsstr. 150 * * D-44780 Bochum * * Tel: +49 234 700 6434 * * Fax: +49 234 709 4162 * * Voice/Fax Box: +49 2561 91371 2056 * * http://www.lstm.ruhr-uni-bochum.de/~demmer * *************************************************************