Access violation while linking.

I received the following error while linking:

00405443 load(<ptr>unsignedÄchar,int) [+0906] 00409382 load_static_library(<ptr>structÄobj_file_list) [+030a] 0040115a main [+10ac]

Here is what SLINK64 told me:

00409382 load_static_library(<ptr>structÄobj_file_list) [+030a] 0040115a main [+10ac]

Here is what SLINK64 told me:

00409382 load_static_library(<ptr>structÄobj_file_list) [+030a] 0040115a main [+10ac]

Here is what SLINK64 told me:

00409382 load_static_library(<ptr>structÄobj_file_list) [+030a] 0040115a main [+10ac]

Here is what SLINK64 told me: [quote:d7c3b96333]Loading C:\Windows\System32\User32.dll Loading CMAIN.obj Loading GUSER.obj Scanning C-MASTER.lib Scanning C-MASTER1.lib Scanning C-MASTER2.lib Scanning C-MASTER3.lib Scanning C-MASTER4.lib Scanning C-MASTER5.lib Scanning PROJ4LIB.LIB Scanning libharu.lib Scanning pnglib.lib Scanning zlib.lib

I have ZIPPed up all the OBJ's and LIB's at the link below, along with this SLINK64 command line.

[quote:d7c3b96333]SLINK64.exe CMAIN.obj cmain_resources.res GUSER.obj C-MASTER.lib C-MASTER1.lib C-MASTER2.lib C-MASTER3.lib C-MASTER4.lib C-MASTER5.lib PROJ4LIB.LIB LIBHARU.lib PNGLIB.lib ZLIB.lib C:\Windows\System32\User32.dll /file:C-MASTER.exe

Link: https://www.dropbox.com/t/X9OvAlGMBoUicQGS

I forgot to get ALL the text from the error:

Runtime error from program:c:\program files (x86)\silverfrost\ftn95\slink64.exe Access Violation The instruction at address 00405d49 attempted to read from location 0e0d0040 00405443 load(<ptr>unsignedÄchar,int) [+0906] 00409382 load_static_library(<ptr>structÄobj_file_list) [+030a] 0040115a main [+10ac]

eax=0f598550 ebx=0372a2c0 ecx=0e0d0000 edx=00000000 esi=0e0d0000 edi=0fa708ce ebp=0365e7f0 esp=0365e33c IOPL=1 ds=002b es=002b fs=0053 gs=002b cs=0023 ss=002b flgs=00010206 [NC EP NZ SN DN NV]

00405d49 mov ebx,[ecx+0x40] 00405d4c mov [eax],ebx 00405d4e mov [eax+0x4],0x5

Bill

The crash does not occur if zlib.lib is loaded before libharu.lib.

There is then a report of missing symbols. Is this a false report? Is there some inter-dependency between the libs?

Note that user32.dll is automatically scanned by SLINK64 and so does not need to be included in the list.

Bill

I have located one bug in SLINK64 that solves the initial failure but then I get the error report ..

***Unknown Slink64 record type - 0 - probably corrupt object file

How is zlib.lib created? Is it composed directly from obj files or from a mix of obj and lib files.

Maybe I should send you a new SLINK64 and you can experiment with creating zlib.dll in a simpler way.

It is interesting that the ordering would make a difference. The only code needing ZLIB is libHaru, so that's why the ordering was set as such.

I don't build LIB's using LIB's, although I will look to see if something is amiss.

The PM I sent you just a few moments ago is not correct. Working on what is really going on!

I changed the ordering of the libraries. Now, while Scanning pnglib.lib, it then shows 'Loading '...

Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp1.obj

There are 335 of these temp files loaded, then the following at the error stop:

Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp334.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp335.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp1.obj ***Routine png_write_filtered_row has been loaded more than once

Side note, PNGLIB is only built using a Plato project; my MAKE file had not been modified to build it. I mention that because none of the other libraries that are 'Scanned' then have a list of temporary files that are loaded.

I checked and the definition of the routine listed occurs only once. I did a CLEAN in Plato and a rebuild before this SLINK64 step..

Shall I send another Transfer file?

Bill

I am wondering if SLINK64 is clever enough for the tasks that you are attempting. When it loads a lib file it attempts to unpack it to the temporary files that you can see. The fact that there are a large number of them suggests either that something within is going wrong within SLINK64 or that you have one or more extremely large libraries.

Is it necessary to pack so much into one static library? An alternative would be to work with a number of static libraries that are composed by combining only obj files. If you use link scripts then it is easy enough (when linking) to replace one lib file by a number of other simpler lib files that are written into a script.

I split my really large (by count of compiled modules) into 6 pieces. I do admit that the CMASTER.LIB has a lot of things in it; 335 compile objects (hmmm), some of which contain multiple entry points. The other CMASTERx.LIB have very few modules and only a few entry points within a module.

The libraries ZLIB, PNGLIB, and libHaru are small by comparison. ZLIB has 12 compiled modules, PNGLIB has 17 modules, and libHaru has 56 modules.

SLINK and SLIM don't have any trouble handling these objects. My 64-bit build started as almost identical copy of the 32-it build, then the 64-bit unique items had to be handled (like using SLINK64 instead of SLIM), changes in allowable command line options, etc.

[SLINK64 v2.16, Copyright (c) Silverfrost Ltd. 2015-2021] Loading f:\CMASTERF95\RELEASE\win64\CMAIN.obj Scanning f:\CMASTERF95\RELEASE\win64\C-MASTER.lib Scanning f:\CMASTERF95\RELEASE\win64\C-MASTER1.lib Scanning f:\CMASTERF95\RELEASE\win64\C-MASTER2.lib Scanning f:\CMASTERF95\RELEASE\win64\C-MASTER3.lib Scanning f:\CMASTERF95\RELEASE\win64\C-MASTER4.lib Scanning f:\CMASTERF95\RELEASE\win64\C-MASTER5.lib Scanning f:\CMASTERF95\RELEASE\win64\PROJ4LIB.LIB Scanning z:\cmasterf95\zlib\Release\win64\zlib.lib Scanning z:\cmasterf95\libharu\Release\Win64\libharu.lib Scanning z:\cmasterf95\pnglib\Release\Win64\pnglib.lib Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp1.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp2.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp3.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp4.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp5.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp6.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp7.obj . . . Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp333.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp334.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp335.obj Loading C:\Users\msdude\AppData\Local\Temp\Slink64Temp1.obj ***Routine png_write_filtered_row has been loaded more than once

By making a big change to remove all libraries from the link step, I have uncovered something new.

My first indication something was amiss was some of the 'C' routines were 'missing'; that is, their names were unresolved. Turns out, if you don't load these compilation units (consisting of a few to many individual routines) in the appropriate order, the external references come up 'not defined'.

This does not occur with the FTN95 routines (for some reason). They are (mostly) loaded in alphabetic order, and I would have expected some/all of these to be unresolved as well. But they are not. I suspect that the declaration of the functions is causing this, and bears further looking into.

The first SLINK64 was designed to handle executables and DLLs, not static libraries. Static libraries are more of a convenience than a necessity. They are essentially concatenated blocks from separate object files.

Multiple source files can be joined together into one master file by the use of 'include' statements. A master file can then be compiled into one large object file that becomes a 'library' albeit with an .obj extension.

Even then, a number of such .obj libraries can be handled quite easily by using a SLINK64 script.

It is quite possible that SLINK64 may not yet be fully functional in its handling of static libraries. It may need further development in order to provide multiple passes that allow for interdependency between the routines. In the meantime it may be more efficient to avoid the use of static libraries except in simple situations where there is no mutual dependency.

Paul, I have abandoned the static libraries, and have transitioned to only the object files. In my build process, I have no static libraries.

Yet, I still have 'not defined' symbols.

My previous post was about that specific experience, which mystifies me because there are 'not defined' symbols even when I load every object file created.

Still working on the reason behind this in my build/link processing.

I have discovered that one 'C' file would not compile, and yet another was commented out. So, my statements about 'not defined' were incorrect being caused by my own error and a compile error.

I apologize to all.

I am working through my 'not defined', assuming that my compilation modules that contain deprecated code and should be eliminated.