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.