Recent

Author Topic: typshrdh.inc  (Read 841 times)

TRon

  • Hero Member
  • *****
  • Posts: 4148
Re: typshrdh.inc
« Reply #15 on: March 13, 2025, 03:09:09 am »
Now it compiled, but I have utterly no idea what caused it not to compile with all my other pascal files in the same directory.
No problem. Ok, so issue is solved for you now ?

Possible causes:
- residue units from a previous (other version) FPC installation which the compiler picked up on
- similar to the previous a fpc.cfg file that was picked up on (pointing directories to wrong locations)
- a unit in your project named the same as one of the RTL units (that is a no-no). Note that FPC treats units/sources with different casing the same.
- it is possible the compiler thinks/believes a unit has changed checksum and tries to recompile which can be a problem when the RTL is stored in a non-writable location (hence the suggestion to install the compiler in user-space and/or use the by marcov suggested -Ur switch). I myself have never seen that happen for RTL units (though the first time I encountered such an issue with a non RTL unit I switched to installing the compiler into user-space)

Outside those, I have no idea. That is why it would have been very informative to see this happen in your output log so that there might have been a possibility to reproduce.
« Last Edit: March 13, 2025, 03:12:34 am by TRon »
Today is tomorrow's yesterday.

dryzone

  • Jr. Member
  • **
  • Posts: 50
Re: typshrdh.inc
« Reply #16 on: March 13, 2025, 06:38:35 am »
Thanks to Tron & Marcov who helped me get a solution to this problem.

I have enough to work with now to find out what the reason for the problem is and what triggers the compiler this way.
I will figure it out and report back what I find,

Thanks a lot.

TRon

  • Hero Member
  • *****
  • Posts: 4148
Re: typshrdh.inc
« Reply #17 on: March 13, 2025, 07:58:09 am »
You're most welcome dryzone.

If this experience provided some insight on how to analyze the problem then great. If encountered again any additional information would be appreciated.

However, I think (imho) that it would be more beneficial to harness an FPC installation against this kind of mishaps by installing in user space (as for instance any package manager installation from your distro will ruin your current setup) and using a forced Free Pascal configuration file (fpc.cfg) that is not located in any of the standard location it searches for (see documentation).

The configuration file that FPC uses can be forced by using the command-line option -n to ignore loading the default configuration file (if any is in place) and the @ option to point the compiler to the forced configuration file (see also command-line options).

To prevent having to type that each and every time something needs to be compiled that can be solved by using a link, script or shell alias.

If that sounds too complicated then FPCUp(Deluxe) can do such a setup automatically and provides a small fpc shell script that can be used to invoke the stand-alone compiler (just don't use FPCUp(Deluxe) to install to the standard system directory locations as it defeats its purpose)

2 cents
Today is tomorrow's yesterday.

dryzone

  • Jr. Member
  • **
  • Posts: 50
Re: typshrdh.inc
« Reply #18 on: March 13, 2025, 04:39:32 pm »
Thank you for your recommendations.
Installing in userspace is a no no for my circumstances.
That means I have to install on every terminal and laptop and whatever that access the server by ssh.
It is just not practical.

Remember I am not a windows user, where server based applications are iffy at best, and user space installs are the norm.

I never get trouble with Linux server applications and did  not get much using Unix before that.
I am pretty sure that my problem is self inflicted, although in a very creative way,  and the problem encountered in the end has nothing to do with fpc or the installation. 
Once I confirm my hunch I will report back.

 

TinyPortal © 2005-2018