Recent

Author Topic: Maximum size of unit: Internal Error 200205172  (Read 7528 times)

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 365
Re: Maximum size of unit: Internal Error 200205172
« Reply #30 on: September 29, 2020, 02:48:36 am »
Hey PascalDragon. So I reorganised my units so as not to hit that limit, and the windows compile is fine. Then I upgrade to FPC 3.3.1 which appears to have the fix you committed (though I did not revert my code, so I'm not really testing it), but now that I compile for linux, I get the same outcome: linking fails with error

FHIRServerFPC.lpr(438,1) Error: Error while linking

Is this the same error? or something else?

is there anything I should do to investigate?

Blaazen

  • Hero Member
  • *****
  • Posts: 3237
  • POKE 54296,15
    • Eye-Candy Controls
Re: Maximum size of unit: Internal Error 200205172
« Reply #31 on: September 29, 2020, 03:36:41 am »
After updating FreePascal you should rebuild Lazarus too (Tools > Configure Build Lazarus ..., set Clean All). And rebuild your project with Run -> Clean up and Build...
Lazarus 2.3.0 (rev main-2_3-2863...) FPC 3.3.1 x86_64-linux-qt Chakra, Qt 4.8.7/5.13.2, Plasma 5.17.3
Lazarus 1.8.2 r57369 FPC 3.0.4 i386-win32-win32/win64 Wine 3.21

Try Eye-Candy Controls: https://sourceforge.net/projects/eccontrols/files/

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 365
Re: Maximum size of unit: Internal Error 200205172
« Reply #32 on: September 29, 2020, 03:38:22 am »
I Built everything from scratch using FPCUPdeluxe.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #33 on: September 29, 2020, 09:15:55 am »
Hey PascalDragon. So I reorganised my units so as not to hit that limit, and the windows compile is fine. Then I upgrade to FPC 3.3.1 which appears to have the fix you committed (though I did not revert my code, so I'm not really testing it), but now that I compile for linux, I get the same outcome: linking fails with error

FHIRServerFPC.lpr(438,1) Error: Error while linking

Is this the same error? or something else?

is there anything I should do to investigate?

Sounds like a different error. Please list other messages before that one, probably something like Undefined reference or so. Maybe you need to select Copy all messages or similar from the context menu of the message window to get them all.

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 365
Re: Maximum size of unit: Internal Error 200205172
« Reply #34 on: September 29, 2020, 01:01:20 pm »
> Please list other messages before that one

I did a full build. 3783 warnings, 5781 hints, and 1 error which is the linker error. You can reproduce this if you want, btw - it's all open source. Given that the full compile is 1.3million lines of code or so, I'm not in a hurry to try to nail this down by removing things from the program

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #35 on: October 01, 2020, 09:44:36 pm »
Hey PascalDragon. So I reorganised my units so as not to hit that limit, and the windows compile is fine. Then I upgrade to FPC 3.3.1 which appears to have the fix you committed (though I did not revert my code, so I'm not really testing it), but now that I compile for linux, I get the same outcome: linking fails with error

FHIRServerFPC.lpr(438,1) Error: Error while linking

Is this the same error? or something else?

is there anything I should do to investigate?

I don't even get that far cause it fails with the uses of unit Windows in the project file when I compile for Linux. Would you please make sure that the project really compiles for Linux so that I can investigate the linking problems?

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 365
Re: Maximum size of unit: Internal Error 200205172
« Reply #36 on: October 02, 2020, 09:21:14 am »
sorry. if things work how I think they work... I just committed an update and left the compile mode as linux, and it should now compile and show the linking error

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #37 on: October 04, 2020, 05:31:14 pm »
I still had to adjust quite a bit  to get it to compile on x86_64-linux:

  • project was missing paths to ../library/support, ../library/ucum and ../library/snomed
  • you need to make sure that units are used correctly for it to work correctly on case sensitive file systems: FPC first searches for the unit as-is, then lowercase and then uppercase. This applied to the following uses:
    • uses of IdURI in unit FHIR.Web.Fetcher (implementation)
    • uses of IdPOP3 in unit FHIR.Server.Subscriptions (interface)
  • this also applies to the include of fhir.r5.inc where the file is named FHIR.R5.inc which will never match either, so either adjust the includes to FHIR.R5.inc or rename the include to fhir.r5.inc

With this out of the way we come to the linker errors (which ld marks only as warnings, but which are hopefully the same that you see):

Code: [Select]
Warning: linker: /usr/bin/ld: cannot find -liodbc.dylib
Warning: linker: /usr/bin/ld: cannot find -lChakraCore

The ChakraCore is due to me not having it installed (though you'll have to check whether the casing is correct), but the iodbc one is the wrong library name (don't know what it is, but dylib is definitely wrong). You need to fix your constant in FHIR.Database.ODBC.Headers, though FPC will ignore paths as it relies on the OS' search paths (some Linuxes don't have a /usr/lib, but a /usr/lib64 instead).

If you see these warnings as well then that are your problems.

Some further remarks:
  • the target directory is set to an absolute path, you should use a relative one here, too (C:/... will result in the creation of just such a relative path as : is a valid character for filenames)
  • you should study the topic of Lazarus as packages to partition your code as that allows parallel compilation within the IDE (mainly important if you do a full rebuild), but also speeds full rebuilds in general as only the necessary packages will be recompiled (please note that a Lazarus package is not the same as a Delphi package)
  • you should not version the .lps file as that contains session information, but not actual project information and will essentially always conflict if you opened/closed a unit

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 365
Re: Maximum size of unit: Internal Error 200205172
« Reply #38 on: October 06, 2020, 01:08:57 pm »
thanks very much - really appreciate it. So I finally actually got a linux box set up (painful!), and actually compiled on + for linux instead of on windows for linux

* I sorted the paths issues (case sensitivity, as you say)
* The linker issues I'll work on (iodbc.dylib is the filename on OSX). Maybe the compile for linux is bombing on windows because those aren't available?
* target path - right. good point.
* I removed the .lps file from version control. Is there a standard git ignore anywhere for lazarus projects?
* packages....  right. My experience with packages in delphi has made me allergic to them. I'll look at Lazarus projects, though compartmenting my code still sounds scary

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #39 on: October 06, 2020, 01:25:34 pm »
* The linker issues I'll work on (iodbc.dylib is the filename on OSX). Maybe the compile for linux is bombing on windows because those aren't available?

That's what I assume. The ELF format requires the presence of the libraries to link them correctly while PE/COFF does not. Though I wonder why there isn't any further message...

* I removed the .lps file from version control. Is there a standard git ignore anywhere for lazarus projects?

You can use the one we have in FPC.

* packages....  right. My experience with packages in delphi has made me allergic to them. I'll look at Lazarus projects, though compartmenting my code still sounds scary

Lazarus packages are definitely nicer than Delphi packages. A Lazarus package contains a list of files and compiles them to a unit output directory. If a project has a dependency on a package then this unit output directory is added to the list of unit paths  the compiler is called with. If you can nicely partition your code (e.g. separate the ucum stuff) then this will be to your benefit.

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2020
  • Former Delphi 1-7, 10.2 user
Re: Maximum size of unit: Internal Error 200205172
« Reply #40 on: October 06, 2020, 01:29:38 pm »
See the Wiki article Lazarus/FPC Libraries for a table of operating system library filename prefixes and extensions.

Grahame Grieve

  • Sr. Member
  • ****
  • Posts: 365
Re: Maximum size of unit: Internal Error 200205172
« Reply #41 on: October 06, 2020, 11:00:22 pm »
About packages... I think the place for me to start would be the markdown code - make that available as a package for ease of use of others as well. What I don't understand is the interplay between packages and github - how does the IDE find a package? And I presume there is some central repository of packages... how does that work? A quick google didn't find me the doco about that?

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #42 on: October 07, 2020, 09:20:28 am »
Well, there is the Online Package Manager, but it essentially boils down to this: you download a package, you open the package, now the IDE knows about the package and you can use it in code. Only if the package contains design time components and you want to use them with the designer or if the package is an extension for the IDE you need to install it (and thus trigger a build of the IDE).

The MarkDown parser would indeed be a good first step, cause it's definitely independent of your project.

mr-highball

  • Full Member
  • ***
  • Posts: 233
    • Highball Github
Re: Maximum size of unit: Internal Error 200205172
« Reply #43 on: October 07, 2020, 04:18:27 pm »
An alternative to modularize with a git construct would be to use submodules. I use them all the time and find them very easy to work with. When you have a repository that uses them you just add a --recursive flag to a git clone and the source plus all submodule sources will be fetched. They also allow for using versioned libraries in projects and can be updated as needed by simply issuing a git checkout xxx in modules directory.
Because the module is kept like a subdirectory to the project, you can also easily see dependencies just by glancing at the git repo (they show as well in github and can be clicked on to go straight to the source)

https://git-scm.com/book/en/v2/Git-Tools-Submodules

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Maximum size of unit: Internal Error 200205172
« Reply #44 on: October 08, 2020, 09:42:26 am »
An alternative to modularize with a git construct would be to use submodules. I use them all the time and find them very easy to work with. When you have a repository that uses them you just add a --recursive flag to a git clone and the source plus all submodule sources will be fetched. They also allow for using versioned libraries in projects and can be updated as needed by simply issuing a git checkout xxx in modules directory.

Doesn't help however with things like compilation time and such when you do a clean build.

 

TinyPortal © 2005-2018