Firstly, our configuration :

   - Novell Network 3.11
   - MeSs DOS 6.22
   - NO local hard disks

 When I installed DJGPP v2 beta 2 on network drive, I tried to compile
"Hello world" program, and get this :

 L:/jazyky.djgppv2/bin/ld.exe :cannot open linker script file djgpp.lnk

 No, I did not forget to set djgpp.env. I set djgpp.env corectly
and map search drive (path) to djgppv2/bin. 

 I tried to install v2 on the  local disk, set djgpp.env - no problems !
 With latest vesion of gcc v1 - on net drive - no problems

 I compared params and found, that gcc runs ld.exe with parameter -Lthere/are/
libraries, but - when gcc is running on network drives - there is not
parameter -L 

 Second error - makefile (from v2) can not find my makefile - till I wrote
    makefile -f makefile 
- BUT - from local hard disk it is OK, v1 - OK (no -f param needed)

   Daniel Skarda

This problem is truly with Novell.  At our network, we use Novell 3.11 mixed
with various versions of PC & MS DOS 5.0-6.2.  Our computers also have
individual hard drives.

Is this a problem only with Novell 3.11? or is it also present in other versions
of NetWare (such as 4.0)?

  I think, that problem is really in gcc, when I run info.exe (from txi360b-beta3),
- no error, even info.exe has INFOPATH in djgpp.env.

 
  gcc (ld) - LIBRARY_PATH in djgpp.env, but can not find libraries !!!


  Possible errors:

      - NoWell
      - info uses another function (without bug or compatible with Novell)
      - ???

DJGPP v2 - compiling "hallo world"

  gcc -v hallo.c
    ... deleted ....   
  ld.exe L:/DJGPPV2/LIB/crt0.o F:/TEMP/ccdaaaaa -T djgpp.lnk -lgcc -lc -lgcc
   
     can not open script file djgpp.lnk ...

DJGPP v1 

  gcc -v hallo.c
    ...  deleted ...
  ld.exe L:/DJGPP/LIB/crt0.o -LL:/DJGPP/LIB F:/TEMP/ccb00067 -lgcc -lc -lgcc

- no errors  


 Daniel Skarda

The problem is still present in beta 3..

It appears you have V2 installed on your L drive - does this problem
only happen on the L drive, or on any network drive?  Its sort of 
interesting that the drive letter and missing switch are the same 
letter?

DJGPP v2 - network, BUT from local disk:

 gcc -v hallo.c

 ... deleted ...
   
 C:/DJGPPV2/bin\ld.exe C:/DJGPPV2/lib/crt0.o -LC:/DJGPPV2/lib/ f:/temp/ccdaaaaa
   -Tdjgpp.lnk -lgcc -lc -lgcc 

 OK, no problems


DJGPP v2 - network, NETwork drive:

 This error is independent on the letter of network drive (it is not collision
between "L drive" and param)

  Daniel Skarda

  I played with this bug and found this:

DJGPP C (both, v1 and v2) checks library path - but for v2 are all "net" paths
wrong (as directory does not exist)

                                              v1              v2
    C:/djgpp/lib                             yes              yes 
    C:/abcd       (does not exist)            no               no
    L:/djgpp/lib    (net drive)              yes               NO !!!
    L:/abcd       (does not exist)            no               no

 yes - gcc runs ld.exe with -L parametr
  no -  ...

so, possible solution of this error:
   1) disable "check function" or force it to check net paths correctly
   2) run ld.exe separately with  explicit -L param
   3) modify lib/specs file - my temporary solution
       (interesting, gcc.exe can find this file, even if it is in
        the damned lib directory !!!)

solution for make  - write your own make, which executes old make with -f parametr

 But ALL of these solutions does NOT seem sufficiant enough.
 

On a LFN network drive, this turned out to be a problem with the 
stat() call.  In src/libc/posix/sys/stat.c, there is a test program
which you can use to check the status of this directory with DJGPP.
It would be very interesting to know what it thinks.  Then we can try
and track down the problem in more detail.

Possible fix.  In investigating the LFN problem, it appears clearing
the volume bit in the stat define for ALL_FILES may solve this
problem.

The funny thing is, that dxegen works without a problem.
It calls ld correctly with the -L switch.

The reason was that gcc stats /path/to/libs/.
This is pretty normal under UNIX, because /path/to/lib could be
a symlink pointing to nowhere and stat() does not care where it
points to. To be sure the directory exists, one has to add the 
dot. Quite logical, once you found the reason. NetWare however, 
blows this, at least if you use NETX. VLM's behave as they should. 

Eli patched stat.c, the corrected version may be found under
ftp://ftp.lstm.ruhr-uni-bochum.de/pub/djgpp/stat.zip

Probably this change is already incorporated to the new libc,
but I didn't see the 'fixed in WIP' remark for this bug.