How compatable is polink to, lets say from MASM 9.0. LINK?
Dave.
PoLink is usually more up to date than the current available Microsoft linkers.
Hi KeepingRealBusy,
Polink is my preferred linker and it links all my MS COFF object modules produced by ml.exe
Vortex,
I was wondering about the command line differences, but I do not use windows, strictly link with kernel32.lib. It appears that the options I use for LINK should also work for POLINK: "LINK /nologo debug.obj file.obj files.obj kernel32.lib /SUBSYSTEM:CONSOLE /DEBUG /MAP /OUT:files.exe".
I'll give it a try. I need something since my installed Visual Studio 2008 on my Windows 7 system does not link things that linked on Windows XP.
Dave.
Quote from: Vortex on August 07, 2012, 04:32:43 AM
Hi KeepingRealBusy,
Polink is my preferred linker and it links all my MS COFF object modules produced by ml.exe
Vortex,
So much for compatibility. I have attached the POLINK errors and the make file.
Dave
Quote from: Vortex on August 07, 2012, 04:32:43 AM
Polink is my preferred linker and it links all my MS COFF object modules produced by ml.exe
The main source of errors appears to be that it is treating all symbols as global, when, in fact, they are local symbols within a formal procedure. I am not sure why it cannot find the standard WinowsAPI symbols in the system32.lib.
Dave.
I never had a serious problem with Polink. It works fine for me. Can you link the same object module(s) with MS link?
I know this problem because it also occured in jwlink.
the background is: "usually" the COFF symbol table contains only global symbols. However, if you enable symbolic debugging info with -Zi, masm will also write "static" symbols into this table. Those static symbols must not be used by the linker to resolve references, their purpose is just for better debugging support.
Obviously polink does not ignore those static symbols. Also, if you happen to have 2 static symbols with identical names, polink will throw the error mentioned previously.
example
.386
.model flat, stdcall
ExitProcess proto :dword
.code
start:
invoke ExitProcess, 0
p1 proc
label1: ;1. instance of "label1"
ret
p1 endp
p2 proc
label1: ;2. instance of "label1"
ret
p2 endp
end start
So this is definitely a polink bug.
Japheth,
Thank you for the info. I will disable the -zi and try again. Any clue why it can't find the Windows links?
Dave.
Japheth,
No luck. The static symbols ARE multiply defined, by my design.
I guess I will have to abandon polink and try to get LINK to not complain about a wrong version for MSPDBxx.DLL (xx is 80 or 90).
Dave.
Japheth,
Is jwlink compatible with LINK?
Dave.
Quote from: Vortex on August 08, 2012, 03:30:58 AM
I never had a serious problem with Polink. It works fine for me. Can you link the same object module(s) with MS link?
Vortex,
The reason I am looking for a new linker is that Visual Studio 2008 LINK keeps coming up with an error of a bad MSPDB90DLL Version when I try to do a .bat ML and LINK. I have been unamle to link anything.
Dave.
Do you use the "Visual Studio Command Prompt"?
The linker error might be related to an incomplete path.
http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/2a3c57c5-de79-43e6-9769-35043f732d68/ (http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/2a3c57c5-de79-43e6-9769-35043f732d68/)
Google for LNK1101. There is no easy solution other than using the old 6.14 linker that comes with Masm32.
My version is C:\...\Microsoft Visual Studio 9.0\Common7\IDE\mspdb80.dll, 193024 bytes of 7 Nov 2007 - and it doesn't work :(
Ryan,
You were right.
After much thrashing around and several boots, I managed to get LINK from Visual Studio 2008 (MASM 9.0) to execute and I am left with one linking error.
Assembling: dbgfiles.asm
dbgdebug.obj : error LNK2019: unresolved external symbol _SetConsoleMaximumWindowSize@8 referenced i
n function _SetConsoleMaximumWindowSizes@8
dbgfiles.exe : fatal error LNK1120: 1 unresolved externals
I had talked to MS Documentation Support years ago about the lack of documentation for this API in the MSDN documentation, and they researched it and said that the API was unsupported and would go away some time in the future. That time, I guess, is now. I will have to delete the usage of this and re-assemble dbgdebug.asm and then assemble all of the rest of my .asm modules that depend on it.
One thing I found about BCDEdit, it will change the store and subsequent calls to BCDEdit would show the changed value, but if you brought up another CMD window and tried to use the new setting, it was missing. Just like AUTOEXEC.BAT, you need to boot the system so that this new path is used for all subsequent CMD windows. It also helps if you spell the path name correctly (I accidentally used "Program File(x86)" instead of "Program Files (x86)"
Dave
Quote from: jj2007 on August 08, 2012, 06:46:25 AM
Google for LNK1101. There is no easy solution other than using the old 6.14 linker that comes with Masm32.
My version is C:\...\Microsoft Visual Studio 9.0\Common7\IDE\mspdb80.dll, 193024 bytes of 7 Nov 2007 - and it doesn't work :(
JJ, my version from the Visual Studio 2008 is the same: 11/7/2007/ 9:AM 189 KB. Are you sure that the path is correct? Bring up a CMD prompt and type "path". You should see "C:\...\Microsoft Visual Studio 9.0\Common7\IDE\" in the path. The directory should be "Program Files" for XP, and "Program Files (x86)" for Windows 7
Dave
Actually, I don't use paths; instead, I copy the dlls into \masm32\bin - and right now I tested it again, and it works fine with various assembler/linker combinations ::)
jj,
You can do that with some entities, but not mspdb80.dll. I tried to do that by copying it to my tools directory and got the "wrong version". You must use the path for this one.
Dave.
Ok, thanks for the hint. Will try to remember it when the LNK1101 pops up the next time - right now I can't reproduce it. But I have seen it, dear friends from Redmond :icon_mrgreen:
JJ,
I searched for mspdb80.dll in the registry, not there. Then I searched for mspdb80.dll in explorer. I found two version, different sizes, in Visual Studio, apparently one is a 64 bit version and the other a 32 bit version, and guess which one is first - the wrong one.
When I execute I use a 32 bit .exe to kick off a 32 bit CMD window to execute the makeit.bat, so I have to have the 32 bit version.
Dave.
You can take the newer Link.exe and ancilliary files, put them into the MASM bin folder and use them just like older ML.exe/Link.exe.
The issues thrown about MSPDBxx.dll are caused when the copy is done incomplete, you need ALL of the files used. You can avoid this by not linking with debugging information but that is pointless, easier to just copy the right files the first time and be done with it.
I am currently preparing for work, otherwise i would compile a list of the files needed, i'm using ML.exe and Link.exe from Visual Studio 2010 so i can have a play with AVX code, not just relying on macros to insert bytes to accomplish it.
HR,
Ghandi
Ghandi,
Thank you for the reply. I will await your list.
I have ML and LINK working now, and have my PATH problem worked out. All seems to work correctly now, at least for 32 bit compiles. Now I need to dabble in 64 bit for a while. Wish me luck!
Many of my 32 bit executables (.exe's) I brought from my windows XP system will not run on Windows 7. I may have to go the route of a VM and install XP to really be satisfied.
Dave.