v5.00 Renamed .mcl files not usable - confirmed

[Dany]

Something is wrong if an .mcl file was renamed from its original name (e.g. Fat32.mcl) to a more dedicated name (e.g. Fat32_SPIx.mcl). If one tries to use the renamed .mcl file then an “internal error” occurs (I think from v5.00 onwards, I have never seen it before).

For more details, see http://www.mikroe.com/forum/viewtopic.p ... 96&start=7 and its predecessors.

Thanks in advance!

[rajkovic]

Something is wrong if an .mcl file was renamed from its original name (e.g. Fat32.mcl) to a more dedicated name (e.g. Fat32_SPIx.mcl). If one tries to use the renamed .mcl file then an “internal error” occurs (I think from v5.00 onwards, I have never seen it before).
For more details, see http://www.mikroe.com/forum/viewtopic.p ... 96&start=7 and its predecessors.
Thanks in advance!

We had never done renaming of mcl, as far as I know there was no changes that should introduce this behaviour.
If you edit mcl file you will see that original source file name is written in it, think that there was always problem
in some cases if you alter mcl file name.
Mikroe libraries have separate source for each different instance of library.

Nevertheless send me project and mcl that causes this behaviour and we will inspect the reasons of internal
error.

[Dany]

Something is wrong if an .mcl file was renamed from its original name (e.g. Fat32.mcl) to a more dedicated name (e.g. Fat32_SPIx.mcl). If one tries to use the renamed .mcl file then an “internal error” occurs (I think from v5.00 onwards, I have never seen it before).
For more details, see http://www.mikroe.com/forum/viewtopic.p ... 96&start=7 and its predecessors.
Thanks in advance!

We had never done renaming of mcl, as far as I know there was no changes that should introduce this behaviour.
If you edit mcl file you will see that original source file name is written in it, think that there was always problem
in some cases if you alter mcl file name.
Mikroe libraries have separate source for each different instance of library.

Nevertheless send me project and mcl that causes this behaviour and we will inspect the reasons of internal
error.

Ok, thanks.
I will send you a small project.

[Dany]

Hi, I did file a support ticket with the following content (Ticket ID: AJY-623209):

ref: http://www.mikroe.com/forum/viewtopic.php?f=86&t=36846

Hi, here is a small test project that shows the phenomenon attached in the zipfile. Normally the source of the Fat32 library is not provided, only the .mcl file which should be placed in "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Uses\P18".
The project "uses" the Fat32 library via a "uses" clause in the sourcefile.

First situation: The Fat32 library has normally the name "Fat32.mcl". If so, then the project compiles without any errors. The uses clause in the main unit should mention "Fat32" for this.

Second situation: If the fat32 library is e.g. renamed to "Fat32_.mcl" and the uses clause is adapted accordingly, then the error "Internal error 'R12' P18F2620.mpas" pops up.


The difference between the 2 situations is only the name of the library file.

Important: I added also the source of Fat32 for documentation. Please make it ABSENT during your tests (it is not provided together with the .mcl file).

The zipfile: http://www.rosseeld.be/DRO/PIC/TestRenameMCL.zip

[rajkovic]

First situation: The Fat32 library has normally the name "Fat32.mcl". If so, then the project compiles without any errors. The uses clause in the main unit should mention "Fat32" for this.
Second situation: If the fat32 library is e.g. renamed to "Fat32_.mcl" and the uses clause is adapted accordingly, then the error "Internal error 'R12' P18F2620.mpas" pops up.
The difference between the 2 situations is only the name of the library file.
Important: I added also the source of Fat32 for documentation. Please make it ABSENT during your tests (it is not provided together with the .mcl file).
The zipfile: http://www.rosseeld.be/DRO/PIC/TestRenameMCL.zip

After check with debugger result is this:

mcl has info about from which source it is made and this file name is written in mcl.
This is reason why you can not use simple rename on mcl. File name is of key importance for linker
to produce all needed infos.

If I remember correctly reason why we had to put file name in mcl is more obvious in C
you can by means of include (which is not recommended) to include source file C in another C.
So you have more than one source file that is incorporated in one mcl =>
to have dbg possible you have to have list of source files that have been compiled
to create that 1 mcl and this is what is written to mcl.

As a side effect is that rename of mcl can make linker miss offset and throw internal error.

This limitation was there from beginning and if some of projects worked with renamed mcl it
was by accident and not because it should.

[octal]

If I remember correctly reason why we had to put file name in mcl is more obvious in C
you can by means of include (which is not recommended) to include source file C in another C.

Hi Rajkovic,
I think that the precompiled mcl file need to include original file name mainly because it's mandatory for source level debug. Actually, mikroE compilers generates COFF file for debug, these files have all information needed to link actual generate binary code to the source code from which it was generated, this includes the source file name and the line number!!!

[rajkovic]

If I remember correctly reason why we had to put file name in mcl is more obvious in C
you can by means of include (which is not recommended) to include source file C in another C.

Hi Rajkovic,
I think that the precompiled mcl file need to include original file name mainly because it's mandatory for source level debug. Actually, mikroE compilers generates COFF file for debug, these files have all information needed to link actual generate binary code to the source code from which it was generated, this includes the source file name and the line number!!!

yes exactly what I have written few lines below in previous post

to have dbg (debug file and source debug) possible you have to have list of source files that have been compiled

we use dbg file for mikroE debug and generate COFF just for MPLAB if it is requested.

[Dany]

After check with debugger result is this:

mcl has info about from which source it is made and this file name is written in mcl.
This is reason why you can not use simple rename on mcl. File name is of key importance for linker
to produce all needed infos.

If I remember correctly reason why we had to put file name in mcl is more obvious in C
you can by means of include (which is not recommended) to include source file C in another C.
So you have more than one source file that is incorporated in one mcl =>
to have dbg possible you have to have list of source files that have been compiled
to create that 1 mcl and this is what is written to mcl.

As a side effect is that rename of mcl can make linker miss offset and throw internal error.

This limitation was there from beginning and if some of projects worked with renamed mcl it
was by accident and not because it should.

Thanks for the info and the confirmation Rajkovic!

I do use an other method now:
If I want several different .mcl files from one source I make several copies of the one source with the name I want the .mcl files to have.
Thanks again!

[Dany]

Hi, this is a batch file to show how it all works to compile one source file to different .mcl files (compiler directives making the difference are present in a .pld file each time).

http://www.rosseeld.be/DRO/PIC/__Build_ ... _SDMMC.txt

In the batch file you will notice that 4 versions of the Fat32 library and 2 versions of the SDMMC_Utils library are generated.
The "FindStr" batch command is to make visible the result of each compilation.

See also the new article http://www.rosseeld.be/DRO/PIC/index.ht ... _compiling describing more generic library compilation possibilities.

Have fun!