Mail Archives: djgpp/1996/08/18/16:46:35
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 *
*************************************************************
- Raw text -