Dll link error - is it possible to fully expose build commands in EC

[caonen8425]

Easy Code 2.02.0.0017, MASM32, Windows 7 Pro

Am trying to build a Dll project (my first with EC), and getting the following solid link error:

       "File 'c:\users\public\MyProjects\EC\HexToDll\Release' (external object file) not found in project folder.  Cannot build the project."

...followed by the 2nd error message:  "Bad linker command line options"

To make sure the project 'should' link, I copied the EC project sub-folder structure to a separate folder and ran the 'link' command in a batch script using identical link options as specified in the EC project link command line properties.  To avoid unresolved external references, I had to tell the linker to look in the 'release\' subdirectory for the obj files.  Otherwise, the batch script 'link' worked as desired.

The EC link error message appears to be about not finding an .obj file, but tweaking the link command line in the project properties has not helped [at all].  I just keep getting the same error message.

Is there a way to fully expose the commands issued by EC during the build operations?
 

[jj2007]

Check if the assembly succeeded. Obj not found means usually that assembly failed.

[caonen8425]

Object files are in the 'release\' subfolder of the project.  But, to ensure the .objs are ok, I added the orig source files to this project (from the 'static lib' project where they live), and did a 'rebuild all' of the dll project instead of simply a 'build dll'. So the objs were successfully rebuilt from fresh source assemblies within this dll project.

The linker failed with the same error.

I'd really like to see, char-by-char, the build commands being issued EC.  I haven't found a way to do this. How can I do this?
   

[jj2007]

The simplest way is to temporarily replace the assembler and/or linker executables with fake executables that show the commandlines.

I've hacked together what you need, see attachment.

Before extracting the archive to \Masm32\bin:
- rename ML.exe to ML_org.exe
- rename link.exe to link_org.exe
- rename polink.exe to polink_org.exe

Then build your projects normally. If you see less than two boxes, it means that EC uses other executables

Let me know how it works

[rsala]

Hi caonen8425,

Sorry for the inconveniences.

Easy Code is made to build projects automatically and it works perfectly well if everything is well configured.

Could you please attach the Dll project so that I can see where the problem is? Thanks.

Regards.

[caonen8425]

JJ2007, rsala,
 
JJ, Norton360 did not like ml.exe, link.exe, and polink.exe in your zipped file, and promptly removed them before I could use them. Not sure why Norton thought they were unsafe, and I didn't yet attempt to get around it.  But I appreciate your response.

rsala,
My project was so tweaked, I re-created it from scratch, and am getting the same linker error.
The state of the dll project, as attached, is:
1) I created the dll project (HexToDll)
2) I added my two .obj files destined for the dll library, from another 'static lib' project. The obj files are HexToAscii and HexToHexChars.
3) In the HexToDll.def file, I 'exported' the above two objects along with the HexToDll object (with DllEntryPoint) auto-generated by EC.
4) Ran the Rebuild All. HexToDll.asm assembled without error, and the linker failed as described above.

Thanks for looking at this.

[jj2007]

Norton360 did not like ml.exe, link.exe, and polink.exe in your zipped file

Throw Norton into the dustbin, immediately! The three executables have 2048 bytes, there is not even space enough to place malware. Did you know that we have a dedicated sub-forum called AV Software sh*t list?

Besides, the sources are also included, so you could re-build them. If you want to continue to use that Norton crapware, find out how to disable it for the \Masm32 folder and all its subfolders, because Norton will definitely eat many of your freshly built own executables.

[rsala]

Hi caonen8425,

First of all, the ml.exe, link.exe, and polink.exe ARE NOT in my zipped file. They are part of the MASM32 SDK and, as far as I know, those files are absolutely clean. Some anti-virus give false positives with assembler files.

Well, let's see:

The ".def" file (HexToDll.def) only can contain functions exported by this Dll project and the references you put there are not part of this project, so they cannot be there. Once those files are removed, the linker does not find some reference in the "HexToHexChars.obj", then if you remove it from the project everything goes fine.

The problem is in the "HexToHexChars.obj" file, which is an external file, and I cannot know why it fails because I do not have the source code.

Remove the files in the "EXPORTS" section of the "HexToDll.def" file, then remove the "HexToHexChars.obj" from the project and it will build without problems. After that you will have to find out what is wrong with "HexToHexChars.obj".

Regards,

Ramon

[caonen8425]

rsala,

With your feedback in mind, I have done additional testing, with the following results:

1) With only one of the 2 external object files 'added' and 'exported' in my dll project, the build has no problem, regardless of which of the two objects I to add.

2) With both external object files added to my dll project, the build fails as documented above. And the failure always occurs on whichever object is listed second in the .def export list.

3) If, instead of object files, I add the corresponding .asm files to the dll project, the build assembles all the source and has no problems linking multiple objects into the .dll.


So, is it a design limitation that only a single external object file can be successfully added to a project?  I noticed in the EC doc there is such a limitation relative to external 'resource' files.

[hutch--]

Apart from crappy AV scanners which is always a problem, using a computer for development is a different task to a domestic computer used by non-skilled people for general purpose use. You should be developing in a user profile that does not provide the restrictions that an AV scanner of that type puts in place. It also means you must secure the computer properly without relying on badly designed consumer ware.

If you have to have a junk AV scanner on your computer, create a new profile that is free of that type of control and do your development on that profile.

[rsala]

caonen8425,

Hutch already made clear the problem about AV scanners. I always use MASM32 for 32-bit projects and there was never any problem.

The only thing I could see in 'HexToDll' project is that the linker ('link.exe') complained about some missing external reference. If you could send me (or attach) the project that works I would be able to see if there is some bug in EC. Thanks.

[caonen8425]

rsala,

Sorry for the delay in getting back.  Per you request, I've attached 3 Dll projects, two that worked, one that failed.  I tried to name them according to the program elements included in each project, and whether the corresponding build succeeded.  Thanks much for checking into this.

[rsala]

caonen8425,

Thank you very much for your help! I really appreciate it!

With your attachments I could see that there is a bug in EC and I am going to fix it right now. In an hour or two I will release a new version and all your DLL projects will build fine.

Regards and thanks again,

Ramon