A simple CGI program - why "Application type not supported"? lazarus / 38-Networking and Web Programming ---------------------------------------------------------------------- teamtempest · 2014-03-23 23:20 Using Lubuntu 13.10, Lazarus 1.2, FPC 2.6.2. The program in question was originally developed in Delphi 6 for Win32. 100Kb executable. Tested using a small local server (TinyWeb). Works fine. Circumstances suggested a Linux executable might be preferable. Program re-compiled with minimal source changes (basically in how environment variables were retrieved) using Lazarus and FPC for Win32. 250K Windows executable. Performance is the same as the Delphi version. Cross-compiling from Windows to Linux was the original idea (the next step after showing an FPC version worked at all). Possible in theory, but in practice it's so hard to find out how that a native Linux version seemed easier. So: Lubuntu, Lazarus and FPC installed on an older machine. The same source again compiles, except the output is much bigger now (600K) and the message window declares the the application type (console) is not supported on the target. First time that message appeared I then set the target explicitly (Linux/I386 family/default), which I hadn't done previously (presumably some kind of default was used for the first two entries). Same message again. I haven't actually tested the CGI app on Linux because I don't happen to have a local web server installed yet (any suggestions?). So I don't know if the message can safely be ignored. Or even why it appears at all, since Lubuntu obviously has a command line window I can use. Any ideas? Also, why is the exectuable so much larger? Should I skip Lazarus and just use FPC directly? I notice the IDE inserted a line - "Application.Title := 'blahblahblah'" - into the main source file. Which caused an error, and as I couldn't see why a console application would need such a thing, I removed it. I suspect Lazarus may be adding in a whole lot of other things that might account for the size bloat. Clicking on the '*.lpr' file in a Windows directory causes Lazarus to start up showing several files in the editor, only some of which I wrote. I don't understand why a regular expression parser is one of the new files, nor why PalmOS headers are another. So far that hasn't happened in the Linux Lazarus - clicking on the '*.lpr' file doesn't cause anything to happen, actually. ---------------------------------------------------------------------- Leledumbo · 2014-03-24 01:30 See the first line of: http://www.freepascal.org/docs- html/prog/progsu86.html Welcome to Linux world. QuoteAlso, why is the exectuable so much larger?It will always be, but it depends on the configuration and the how the app is coded. For LCL apps, the difference should be around 300K max. Console apps usually have much smaller difference. If not, then something is wrong. QuoteI notice the IDE inserted a line - "Application.Title := 'blahblahblah'" - into the main source fileIt's automatically added if you set Application Title in project options. I don't know whether this applies to any project type or only LCL based ones. ---------------------------------------------------------------------- teamtempest · 2014-03-24 16:26 Thanks for the link. That explains it, somewhat (as new to LinuxWorld, it's a bit difficult at the moment to reconcile "all programs are console apps" with the GUI desktop environment). The offending line might have no effect in Linux but isn't exactly ignored, so I believe I will just change it to this: Code: [Select] {$IFDEF WINDOWS} {$APPTYPE CONSOLE} {$ENDIF} Which should behave on all platforms I might want to move the code between. Other things still puzzle me. There are some filename errors under the 'uses' clause in the main unit. I don't know if I made them or the automatic conversion process made them. But either way, the source compiles (under both Windows and Linux). The main unit doesn't actually use any of the mis-named files directly, and they are correctly named in the units which do. Hmm. So if I mis-named a unit which the main unit actually needed, this would have shown up as an error? As it is, I noticed the problem only because checking "unit dependencies" (a nice feature) showed the mis-named files with a question mark symbol next to them. Now that's the sort of thing I would have liked to see a warning about! ---------------------------------------------------------------------- Leledumbo · 2014-03-24 23:39 QuoteThere are some filename errors under the 'uses' clause in the main unit.Such as? And what are the error messages? Note that there used to be problems in *nix world due to fpc generating compiled units with mixed case as how it's written in the source code instead of how it's named on disk. This could cause problems on *nix because the file system (at user level) is case sensitive. QuoteSo if I mis-named a unit which the main unit actually needed, this would have shown up as an error?Surely. The compiler can't find the correct file, it will tell you and stop the compilation. ---------------------------------------------------------------------- teamtempest · 2014-03-25 14:41 QuoteSuch as? And what are the error messages? The "uses" clause in the backup original *.dpr file (ie., before Lazarus converted it) looks like this now: Code: [Select]uses   SysUtils,   UIhandle in 'UIhandle.pas',   nodeid in 'NODEID.PAS',   NodeName in 'NODENAME.PAS',   ndctynam in 'NDCTYNAM.PAS',   ndctyabb in 'NDCTYABB.PAS',   ndctyzip in 'DCTYZIP.PAS',   ndnghbr in 'NDNGHBR.PAS',   NodeDist in 'NODEDIST.PAS',   CalcPric in 'CALCPRIC.PAS',   GoshNums in 'OSHNUMS.PAS',   ndoffset in 'NDOFFSET.PAS'; This is a complete list of all the units I wrote (except for 'SysUtils', of course). Most of the names on the left match the names on the right, but two do not. 'DCTYZIP.PAS' and 'OSHNUMS.PAS' are missing an initial letter. It's possible I introduced those errors when I moved all the source files into the same directory and had to edit this part to reflect that. The thing is that even with those incorrect names the program compiles without errors or warnings. There are no error messages related to this issue. The single error message I got was caused by '{$APPTYPE CONSOLE}', and after I wrapped that in an {$IFDEF} there are no error messages at all. As I said, I only noticed it because I used the 'Unit Dependencies' option in the IDE and discovered those two names were flagged with question mark symbols. However, the way the program is organized the only unit actually directly used by this *.dpr/*.lpr unit is 'UIhandle' (this unit and 'UIhandle' are the only platform-specific units; all the others are generic Pascal that works the same anywhere). Perhaps that may have something to do with why the compiler didn't care. ---------------------------------------------------------------------- howardpc · 2014-03-25 16:08 Quote from: teamtempest on March 25, 2014, 03:41:03 pmThe thing is that even with those incorrect names the program compiles without errors or warnings. This is because FPC and Lazarus are cross-platform, and so the simplistic Delphi syntax of Code: [Select]  uses unitname in unitfilename; is pretty much useless, since it adds no new information. Redundant information can quickly go stale. The IDE knows from the new units you have generated and added to your project where the source files are and what you have called them; and it knows where you have specified the output .ppu files should be stored; and it knows where the ppu files of all registered packages you might use are, and where to find the RTL/FCL/LCL ppu files etc. It makes sure all this unit path information is kept updated and passed to the compiler when you build your project. Consequently the IDE ignores the "in yyy" of "uses xxx in yyy;" and accepts that syntax only for reasons of Delphi compatibility. You are best advised to strip out all "in yyy" parts of uses clauses carried over from Delphi ports to Lazarus. They are dead wood, and as you have found may also be misleading or totally incorrect. The IDE does its best to enforce the exact correspondence of the Pascal unitname with its OS filename, and encourages you to name all unit filenames entirely in lowercase to aid sharing code in a cross- platform way without easily avoided naming errors. So a file named sysutils.pp on disk may refer unambiguously to a Pascal unit named sysutils, or SysUtils or SYSUTILS etc. The discrepancy between the case sensitivity of many OSs and the case-insensitivity of Object Pascal is a fact one has always to bear in mind when it comes to naming.