We ran 2.1.84 with no problems. We recently upgraded our build
environment to 2.1.102. (We've been using 2.1.102 in application
testing for a couple of months so we decided it was stable enough
to use for compiling and linking too).
Immediately after upgrading, we noticed that our executable files
were corrupted during the link phase of a build. Remember that
the objects and the executable are all stored on the UltraSparc
server. If we link under Linux 2.1.84 then there is no corruption
and if it is 2.1.102 then there IS corruption.
====> I've repeated this with 2.1.115 so the bug is still alive
====> in the latest edition of the kernel.
This is a very puzzling bug. We do NOT see corruption when we link
directly to the local hard drive and we don't see corruption when
we NFS mount another 2.1.102 Linux box and link on its file system.
The only corruption occurs when running 'ld' under 2.1.102 (or
2.1.115) and writing the executable to a SunOS 5.5.1 NFS server.
(BTW, we using GNU ld version 2.8.1 (with BFD linux-2.8.1.0.1)).
I can spend some time helping with a 'remote debug' of this problem
if there are tools, logs, debug switches, etc, that can be thrown
to gather data here. I also have a set of objects which I can probably
ship to a Linux developer to reproduce this bug. He/she just needs a
SunOS box handy. Alternatively, the NFS/TCP/UDP developer's can try
to track the source differences between 2.1.84 and 2.1.102.
IMHO, its a serious problem which needs attention.
-Ben McCann
-Ben McCann
--
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmccann@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html