Subject: GetTempFileNameA likely cause of link.exe error under NetBSD+Peace
To: None <peace-sacrifice@hauN.org>
From: Alicia da Conceicao <alicia@engine.ca>
List: port-i386
Date: 03/02/2004 13:59:30
Hi again:

I have managed to also get both the Win32 "cl.exe" and WinCE/PocketPC
"clarm.exe" compilers to work under NetBSD+Peace, and these produce
the proper object files that I can transfer to a windows system and
successfully link into working Win32(98/ME/2000/XP) and working
WinCE/PocketPC binaries.

Of course, I still need to get "link.exe" to work in NetBSD+Peace so
that I can link the windows binaries from the object files without
having to transfer them to another computer.

I have examined the "link.exe" further, and it would appear that either
GetTempFileNameA fails (can't generate a proper temp filename), or the
filename it provides has an invalid path.  As I mentioned previously, I
am still the "TMP" & "TEMP" environment variables to a proper temporary
directory ("C:\tmp") which under Peace is translated to "/sec/tmp" on
my NetBSD filesystem.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/gettempfilename.asp

Does anyone know anyway that we find out what if any temp filename
that the "link.exe" binary is trying to use?  "ktrace link.exe" does
not help.

BTW, this "link.exe" I am trying to use came with VC++ (from Visual
Studio 6.0).  When I attempt to use the newer "link" that comes with
eVC++ (Embedded Visual Studio: WCE400-420), it would SEG-FAULT:
==============================================
         PF_FLOATING_POINT_PRECISION_ERRATA
SetUnhandledExceptionFilter 0x7800b3b9
LOCALE_IDEFAULTANSICODEPAGE
IsValidLocale [not implemented]
LOCALE_SENGLANGUAGE
LOCALE_SENGCOUNTRY
LoadCursorA [not implemented]
IDC_ARROW
LoadCursorA [not implemented]
IDC_ARROW
Segmentation fault
==============================================

and below is the end piece of a ktrace dump of this newer "link.exe":
==============================================
  22879 link.exe NAMI  "."
  22879 link.exe RET   open 9
  22879 link.exe CALL  chdir(0xbfbfe434)
  22879 link.exe NAMI  "/emul/pecoff/dos/opt/wince/evc/wce420/bin"
  22879 link.exe NAMI  "/dos/opt/wince/evc/wce420/bin"
  22879 link.exe RET   chdir 0
  22879 link.exe CALL  __lstat13(0xbfbfe452,0xbfbfe3a4)
  22879 link.exe NAMI  "link.exe"
  22879 link.exe RET   __lstat13 0
  22879 link.exe CALL  __getcwd(0xbfbfe434,0x400)
  22879 link.exe RET   __getcwd 30/0x1e
  22879 link.exe CALL  fchdir(0x9)
  22879 link.exe RET   fchdir 0
  22879 link.exe CALL  close(0x9)
  22879 link.exe RET   close 0
  22879 link.exe CALL  break(0x4c5000)
  22879 link.exe RET   break 0
  22879 link.exe CALL  break(0x4c8000)
  22879 link.exe RET   break 0
  22879 link.exe PSIG  SIGSEGV SIG_DFL
==============================================

I would greatly appreciate any assistance on getting any version of
Microsoft's "link.exe" to work under NetBSD+Peace.  Alternatively, I
would also appreciate any suggested alternatives to "link.exe" that
I can use with NetBSD to link my windows object files.  I discovered

"i386-mingw32-ar" & "i386-mingw32-ranlib" can be used as an
alternative to "lib.exe" to created proper windows library (*.lib)
files from native windows object files, that can be linked into
working binaries.  Unfortunately, I have not had any luck getting
"i386-ming32-ld" to link my native windows object files into
working binaries that don't SEG-FAULT.

Getting "link.exe" to work under NetBSD+Peace is still my first
choice, since it can also link WinCE/PocketPC object files into
WinCE/PocketPC binaries.

Thank you in advance.
Alicia.