View previous topic :: View next topic |
Author |
Message |
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Sun Oct 01, 2017 4:03 pm Post subject: Can the latest ClearWin+ be used with other 32bit compilers? |
|
|
I am unable to call the latest ClearWin+ from a 32 bit app built using Microsoft C as it crashes. I am able to call it from the same source compiled for 64 bit (swapping the lib / dll to the 64 bit ones).
Details
I have managed to build a small 'hello world' executable using the Microsoft C compiler (cl.exe) and link it against the v13 DLL / LIB of ClearWin+ (as obtained from the 'new features in ClearWin' post, here - http://forums.silverfrost.com/viewtopic.php?t=3529).
In a 64 bit build, there is a separate LIB and DLL (ClearWin64.lib/ClearWin64.dll) and this executable works as expected (a window with a caption is created).
When linking in 32 bit, I use salflibc.lib / salflibc.dll as there does not seem to be an independent ClearWin32 build any more (there was one, available from http://www.silverfrost.com/57/using_clearwin_with_non-silverfrost_c_compilers.aspx but it is outdated now). This compiles and links fine, but throws an exception of;
Quote: |
Unhandled exception at 0x100BE928 (salflibc.dll) in mshello32.exe: 0xC0000005: Access violation reading location 0x00000000.
|
I do not have any other DLLs or libraries used in these examples. Should I be calling an 'init' function before calling ClearWin in 32 bit? I see '__initialise_clearwin_plus' in the exports, but no documentation.
'Hello ClearWin+ source'
Code: | extern int _cdecl __winio(char* format, ...);
int main()
{
__winio("%ca[Window caption]");
return 0;
}
|
To compile the 32 bit I use;
Code: | cl mshello.c salflibc.lib |
To compile the 64 bit I use;
Code: | cl mshello.c ClearWin64.lib |
The 32 bit code can be made to work by going back to the ClearWin32 lib / dll in the 'Using ClearWin+ with non-Silverfrost C compilers' post linked above but this would mean the 32 and 64 bit versions of the app depend on different releases of ClearWin+.
Any help would be appreciated.
Ryan |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Oct 02, 2017 8:00 am Post subject: |
|
|
To my knowledge there is no documentation on how to link a (32 bit) Microsoft C frontend with the ClearWin+ library. Given that, for you, it no longer works, it might be possible for you to link via SLINK, otherwise the only way forward may be for us to upload a new release of the 32 bit ClearWin+ dll. |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Mon Oct 02, 2017 12:38 pm Post subject: |
|
|
From my tests, SLINK has issues with the COFF output from the Microsoft compiler as there are duplicate section names inside the object file.
It's for this reason that I'm trying to access winio via another set of compilers.
I'd love to use the Silverfrost toolchain but the latest 64 bit C++ compiler is not stable.
If there was any chance of an updated DLL it would be very helpful. It would also help me call the winio API from gFortran (I'll create another post about that). |
|
Back to top |
|
|
Ryan
Joined: 25 Feb 2016 Posts: 110
|
Posted: Mon Oct 02, 2017 5:43 pm Post subject: |
|
|
Just a note, if you are able to upload another version of the 32 bit ClearWin+ lib/dll.
There is an additional problem linking code generated by 3rd party compilers with the ClearWin+ symbols contained in the salflibc.lib / dll (the v13 ones).
The problem is that salflibc.lib contains a definition for atexit which has already been output in the object file from the gFortran compiler. This leads to duplicate object names and a linker error.
The 64 bit does not suffer this problem as it has been split into its own library (ClearWin64.lib/dll) that does not contain any of the standard Salford C library code.
I don't know whether it is feasible to split the 32 bit code into two files, in the same way that the 64 bit has been done.
We have an up to date licenced copy of the Silverfrost compiler and I can request the business purchases a support contract if this would help cover the work involved.
Regards
Ryan |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Oct 02, 2017 7:33 pm Post subject: |
|
|
I expect that atexit can be excluded from the 32 bit build if that is not already the case.
P.S. Actually, I assume that a new build of clearwin32.dll would be independent of salflibc.dll so the atexit conflict should not arise. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Oct 03, 2017 11:36 pm Post subject: |
|
|
it would seem to me that a revision of clearwin32.dll 'for use with other compilers' would be leaving open future developments to not being included in that version.
e.g. imagine you release a 'working' clearwin32.dll for other compilers update next week and then say a new overall release before the end of the year (just a hyporhesis that). In that case the clearwin32dll for other compilers would be automatiìcally out-of-sync again.
Why not split off a clearwin32.dll/lib from the saldlibc.lib/dll for the main build and then just ensure that it can be used with other compilers also.
That way it'll be streamlined.
Otherwise the situation mentioned by Ryan of using a build of clearwin32 for use with other compilers oould well arise in the future. This is a fact of life as the burden of updating 3 different files with updates instead of just 2 will inevitably become over-burdening and it won't always be able to ensure it's done. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Oct 04, 2017 8:04 am Post subject: |
|
|
Thanks John
It would be easier and better for us to provide clearwin32,dll with our full release and leave salflibc.dll as it is. We could consider doing that. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
|
Back to top |
|
|
|