[SOLVED] PureBasic 5.51 x86: Updating POLINK.exe

[Crusiatus Black]

Hi all,

When trying to find a solution for the problem described in this thread; http://www.purebasic.fr/english/viewtop ... 13&t=70186 I figured out how to compile my library without __chkstk_ms calls, perfect. The only thing I had to do in order to be able to load this library in my project, was to update polink.exe from the ancient version 5 to the current version 8. This worked beautifully for the x64 of the PureBasic compiler, however it completely messed up PureBasic 5.51 x86.

I'm starting a new thread because this is not part of my original question of updating msvcrt.lib, because I haven't done that yet.

Compiling an empty project (without code) with debugger enabled yields the next error:

Code: Select all

---------------------------
PureBasic - Linker error
---------------------------
POLINK: error: Unresolved external symbol '_SYS_FreeThreadObjectCallback@4'.

POLINK: error: Unresolved external symbol '_SYS_InitThreadObjectCallback@4'.

POLINK: error: Unresolved external symbol '__imp__closesocket@4'.

POLINK: error: Unresolved external symbol '__imp__WSACleanup@0'.

POLINK: error: Unresolved external symbol '__imp__WSAStartup@8'.

POLINK: error: Unresolved external symbol '__imp__PostThreadMessageA@16'.

POLINK: error: Unresolved external symbol '__imp__inet_addr@4'.

...

POLINK: fatal error: 26 unresolved external(s).
---------------------------
OK   
---------------------------

When I disable the debugger, the empty script compiles fine (considering nothing has to be linked), however with one MessageRequester call (and no debugger) the next polink error is raised:

Code: Select all

---------------------------
PureBasic - Linker error
---------------------------
POLINK: error: Unresolved external symbol '__imp__InitCommonControlsEx@4'.

POLINK: error: Unresolved external symbol '__imp__CoInitialize@4'.

POLINK: error: Unresolved external symbol '__imp__MessageBoxW@16'.

POLINK: error: Unresolved external symbol '__imp__GetForegroundWindow@0'.

POLINK: error: Unresolved external symbol '__imp__GetWindowThreadProcessId@8'.

POLINK: error: Unresolved external symbol '__imp__IsWindowVisible@4'.

POLINK: error: Unresolved external symbol '__imp__GetWindowLongW@8'.

...

POLINK: fatal error: 11 unresolved external(s).
---------------------------
OK   
---------------------------

My question; is it even possible to update polink.exe to v8 in the 32-bit PureBasic compiler? I tried it with the latest stable PureBasic as well, same problem. It looks like none of the libraries PureBasic passes onto polink.exe are actually linked at all, weirdly enough.

Hopefully someone from the PB team can also shed some light on this situation, as this is possibly breaking my whole (quite massive) project

[chi]

My question; is it even possible to update polink.exe to v8 in the 32-bit PureBasic compiler?

Yes, it is. But you can't use the pbcompiler.exe anymore (you need to fasm, porc, polink and polib manually + edit .asm, .def) and therefore you also need to have access to all the .lib, .obj, .def, .res,... files.

Why exactly do you want to update polink?

[Crusiatus Black]

Oh boy... Are you sure? Then why is it possible with x64 PBcompiler? I need a newer version of polink, because a static library I compiled with MinGW cannot be linked with polink 5, polink stops responding. Is there another way, perhaps different compilation options for MinGW?

[jack]

I think VS is more compatible with polink, also I am not confident that code produced with gcc is 100% compatible with VS or polink, you may introduce hard to track bugs.

[chi]

Oh boy... Are you sure? Then why is it possible with x64 PBcompiler?

Yup, pretty sure . x64 works because the functions in the .def file are not decorated (as far as I can remember). But it's been a while since I touched that matter...

I need a newer version of polink, because a static library I compiled with MinGW cannot be linked with polink 5, polink stops responding. Is there another way, perhaps different compilation options for MinGW?

Never installed MinGW but have you tried porting your code (or just a portion) to VisualStudio (Community)? I've done some tests in VS (also quite some times ago) with static libs and they worked well with PB's polink5.
But you have to disable following options:

Code: Select all

Security Check -> Disable Security Check (/GS-)
Whole Program Optimization -> No

[Crusiatus Black]

Oh man... Yeah I tried visual studio, I have VS2017 enterprise actually, but the library does not compile it x86 environments of MSVCC due to the assembly code in the project, the x64 compiler in MSVCC only supports it.

I wonder what to do now, Cygwin and GCC didn't work out for me, so MinGW seems the only option - but as it seems that won't work in PureBasic

[jack]

it may work with gcc if you compile to dll, code should be compatible, plus the import lib is easily generated with polib

[Crusiatus Black]

Hi Jack,

I considered that, however the executable will be a portable one - static linking is the absolute preference.

[chi]

And you are absolutely sure your lib will run when you use polink8? Have you tried it with PellesC?

[Crusiatus Black]

Yes I am absolutely sure, the lib is thoroughly tested on x86 and x64 platforms and when I updated polink to v8 in pb x64 it ran as well. The old polink simply crashes when linking my lib with my PureBasic application

[chi]

Send me your lib (stripped down + test.pb, x86/x64) and I'll see what I can do... But no promises ^^

[Crusiatus Black]

Send me your lib (stripped down + test.pb, x86/x64) and I'll see what I can do... But no promises ^^

I sent you the files and some test code, thank you for trying to help!

[Crusiatus Black]

In further conversation with Chi I see a lot of problems when upgrading to a newer version of Polink.

For example, with Polink 8 in PureBasic x64, when building a DLL the symbols are not exported correctly. x86 completely fails because polink can't link against the older (in PureBasic) included libraries. Chi discovered that when a few of the libraries were replaced, the builds started to succeed; but that would probably mean that every library would have to be replaced - not a very viable solution.

I moved back to polink 5 and the library I was using that was conflicting had another version with the fix I was looking for, so I guess we can consider this fixed.