Bug 000020

When Created: 09/05/1995 11:09:06
Against DJGPP version: 2.00.beta2
By whom:
Abstract: DJGPP & versus Novell
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

Note added: 09/09/1995 15:38:42
By whom:
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)?

Note added: 09/19/1995 06:50:40
By whom:
  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 ...


  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

Note added: 09/21/1995 20:53:44
By whom:
The problem is still present in beta 3..

Note added: 09/26/1995 17:18:52
By whom:
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 

Note added: 09/27/1995 12:20:26
By whom:
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

Note added: 10/19/1995 15:51:15
By whom:
  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.

Note added: 01/08/1996 23:29:06
By whom:
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.

Note added: 01/10/1996 20:12:12
By whom:
Possible fix.  In investigating the LFN problem, it appears clearing
the volume bit in the stat define for ALL_FILES may solve this

Note added: 03/14/1996 02:54:58
By whom:
The funny thing is, that dxegen works without a problem.
It calls ld correctly with the -L switch.

Solution added: 07/29/1996 09:00:19
By whom:
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

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

Fixed in version on 04/13/1999 09:00:27
By whom:

  webmaster     delorie software   privacy  
  Copyright 2010   by DJ Delorie     Updated Jul 2010