Recent

Author Topic: Type conversion errors, mucking around  (Read 9691 times)

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Type conversion errors, mucking around
« on: April 14, 2016, 05:37:47 am »
That's the current symptom.  Background: I'm running OpenBSD 5.7 which came with FPC 2.6.4 in ports.  I had that installed, then Lazarus 1.0.14 which I later changed to 1.6.0.  I'm really interested in cross-compiling to Android and I've read that FPC 3.0.0 has some advantages there.  So I uninstalled 2.6.4, copied the 3.0.0 port (it includes 12 patches made by OpenBSD to get it working) from the 5.9 ports (I've done it before).  Built and installed 3.0.0, as far as I can tell successfully.

Now I want to build Lazarus 1.6.0 with it.  Whether I do make clean all, bigide or lazbuild I get this same stop:

Compiling ./widgetset/wscalendar.pp
Assembling wscalendar
Assembling calendar
dbctrls.pp(1422,56) Warning: Symbol "Lookup" is deprecated
dblookup.inc(80,3) Note: Local variable "I" is assigned but never used
dblookup.inc(81,3) Note: Local variable "S" is assigned but never used
Assembling dbctrls
Compiling dbgrids.pas
Compiling grids.pas
Compiling dynamicarray.pas
Assembling dynamicarray
Compiling ./widgetset/wsgrids.pp
Assembling wsgrids
grids.pas(1945,39) Error: Illegal type conversion: "TFontStyles" to "LongInt"
grids.pas(1953,17) Error: Illegal type conversion: "LongInt" to "TFontStyles"
grids.pas(12584) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
Makefile:3666: recipe for target 'alllclunits.ppu' failed
gmake[1]: *** [alllclunits.ppu] Error 1
gmake[1]: Leaving directory '/usr/src/misc/Lazarus/2016-04-09/lazarus/lcl'
Makefile:3080: recipe for target 'lazbuild' failed
gmake: *** [lazbuild] Error 2

I'm thinking I should update by svn to see if that helps, but I installed from a tarball so svn doesn't know the path.  I tried svn update <path> but it doesn't like that.  Googling the error message doesn't find anything.  I notice Lazarus still isn't in OpenBSD ports, so it's possible one of their patches to 3.0.0 breaks something necessary.  svn doesn't seem to work well on my connection, it runs a little while and stops, that's why I fetched the tarball with wget instead.  This is all just common i386 stuff, nothing fancy.

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Re: Type conversion errors, mucking around
« Reply #1 on: April 14, 2016, 04:53:16 pm »
Next morning.  If this were C I'd guess a header file isn't getting loaded.  I'm not sure how many more errors I'm going to get so I don't want to dig into this one too much, thinking on a higher level what could break this (plus whatever else).

Quick test would be to comment the lines out and get on to the next problem.

In grids.pas, CfgSetFontValue() and CfgGetFontValue() are lines:
cfg.SetValue(AKey + '/style/value', Integer(AFont.Style));  and
AFont.Style:= TFontStyles(cfg.GetValue(AKey + '/style/value', 0));
with these things passed in: (cfg: TXMLConfig; AKey: WideString; AFont: TFont)
I don't know where those are defined, worry about it later.

Next stop after commenting those out:
gmake[1]: Entering directory '/usr/src/misc/Lazarus/2016-04-09/lazarus/components/debuggerintf'
/bin/rm -f lib/i386-openbsd/debuggerintf.ppu
/usr/local/bin/ppc386 -FD -MObjFPC -Scghi -O1 -g -gl -l -venibq -vw-h- -vm4046 -Fu../../packager/units/i386-openbsd -Fu../lazutils/lib/i386-openbsd -Fu../../lcl/units/i386-openbsd -Fu. -Fu/usr/local/lib/fpc/3.0.0/units/i386-openbsd/rtl -FE. -FUlib/i386-openbsd -di386 debuggerintf.pas
Free Pascal Compiler version 3.0.0 [2016/04/13] for i386
Copyright (c) 1993-2015 by Florian Klaempfl and others
(1002) Target OS: OpenBSD for i386
(3104) Compiling debuggerintf.pas
(3104) Compiling dbgintfbasetypes.pas
(9009) Assembling dbgintfbasetypes
(3104) Compiling dbgintfdebuggerbase.pp
(3104) Compiling dbgintfmiscclasses.pas
(9009) Assembling dbgintfmiscclasses
/usr/src/misc/Lazarus/2016-04-09/lazarus/components/debuggerintf/dbgintfdebuggerbase.pp(5798,68) Error: (4054) Illegal type conversion: "TDBGEvaluateFlags" to "LongInt"
dbgintfdebuggerbase.pp(6137) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Makefile:2702: recipe for target 'debuggerintf.ppu' failed
gmake[1]: *** [debuggerintf.ppu] Error 1
gmake[1]: Leaving directory '/usr/src/misc/Lazarus/2016-04-09/lazarus/components/debuggerintf'
Makefile:3080: recipe for target 'lazbuild' failed
gmake: *** [lazbuild] Error 2

Debugging stuff, hmm.  My FPC was built without GDB, but that's another can of worms.  This is another illegal type conversion.  They probably have something in common with the previous ones, but what?

I haven't written any Pascal in 7 years, but I started about 1985 with Turbo Pascal 3, used it heavily at times (part of my job) through Delphi versions about 2009.  Never messed with the infrastructure much, but I remember there was a jpeg problem in Delphi 3.  I'd like to see where these types are defined, and it's probably in FPC.

The OpenBSD port of FPC is at ftp://ftp.openbsd.org/ports/lang/fpc/ with the patches in a subdir.  I'll post a link to this topic on ports@openbsd.org but I'm guessing maybe nobody there has built Lazarus using that FPC.

In all 3 cases LongInts are involved, hmm.  I like the trend in C toward int32_t or int64_t myself because they're less ambiguous.  What's a LongInt?  Depends when you ask.  I remember when it was 32 bits, but I would think especially in cross-compiling to other platforms this could be an issue.
« Last Edit: April 14, 2016, 05:11:38 pm by ab1jx »

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Re: Type conversion errors, mucking around
« Reply #2 on: April 14, 2016, 07:36:44 pm »
OK, third one, another type conversion error involving a LongInt:

(9009) Assembling synregexpr
(3104) Compiling synedit.pp
(3104) Compiling syneditsearch.pp
(9009) Assembling syneditsearch
(3104) Compiling syneditmousecmds.pp
(3104) Compiling lazsyneditmousecmdstypes.pp
(9009) Assembling lazsyneditmousecmdstypes
(9009) Assembling syneditmousecmds
(3104) Compiling syneditmarks.pp
/usr/src/misc/Lazarus/2016-04-09/lazarus/components/synedit/syneditmarks.pp(1048,35) Error: (4054) Illegal type conversion: "TSynEditMarkChangeReasons" to "LongInt"
/usr/src/misc/Lazarus/2016-04-09/lazarus/components/synedit/syneditmarks.pp(1062,35) Error: (4054) Illegal type conversion: "TSynEditMarkChangeReasons" to "LongInt"
syneditmarks.pp(1286) Fatal: (10026) There were 2 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Makefile:2702: recipe for target 'allsynedit.ppu' failed
gmake[1]: *** [allsynedit.ppu] Error 1
gmake[1]: Leaving directory '/usr/src/misc/Lazarus/2016-04-09/lazarus/components/synedit'
Makefile:3080: recipe for target 'lazbuild' failed
gmake: *** [lazbuild] Error 2

So TFontStyles, TDBGEvaluateFlags, TSynEditMarkChangeReasons can normally
all be converted to LongInt?  Fishy.  I can see 32 bit unsigned but even that seems absurdly huge since they're basically enums.
« Last Edit: April 14, 2016, 08:23:45 pm by ab1jx »

balazsszekely

  • Guest
Re: Type conversion errors, mucking around
« Reply #3 on: April 14, 2016, 08:31:12 pm »
Make sure you remove every old fpc/lazarus files first(see attachment). Then install FPC 3.0.0 and Lazarus SVN(if it's possible):
http://wiki.lazarus.freepascal.org/Getting_Lazarus#Getting_Lazarus_SVN_development_version

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Re: Type conversion errors, mucking around
« Reply #4 on: April 15, 2016, 06:13:50 am »
I ran your uninstall, then made sure I was installing the OpenBSD 5.9 version from 5.9, not current.  Installed FPC fine, then had the same problem with Lazarus 1.6.  I don't think svn is going to help and I don't have bandwidth to waste.

OpenBSD 5.9 has FPC 3.0.0 with Lazarus 1.4.4 or so, current has 3.0.0 with Lazarus 1.6.  I've looked through their patches several times, there's no magic there, they mostly change install paths and make/gmake.  Yet they install from tarballs, not svn, and as Stuart Henderaon there puts it "I have on i386 about 40 times since fpc 3.0.0 went in, it's unreliable but works more often than not."

This machine's just hosed, I haven't tried 1.6 with 3.0.0 on my laptop.  I don't plan to spend a couple months updating everything any time soon.

But nobody's answered my svn question.  I want to svn update my tarball to the development version.  I don't want to checkout from scratch, I want to update but svn doesn't know the url.  I've tried:

freebie# svn update http://svn.freepascal.org/svn/lazarus/trunk
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# svn update http://svn.freepascal.org/svn/lazarus/trunk .
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# svn update . http://svn.freepascal.org/svn/lazarus/trunk
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# pwd
/usr/src/misc/Lazarus/2016-04-09/lazarus
freebie# cd ..
freebie# svn update http://svn.freepascal.org/svn/lazarus/trunk lazarus
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# svn update lazarus http://svn.freepascal.org/svn/lazarus/trunk
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie#

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Type conversion errors, mucking around
« Reply #5 on: April 15, 2016, 06:34:11 am »
snip

But nobody's answered my svn question.  I want to svn update my tarball to the development version.  I don't want to checkout from scratch, I want to update but svn doesn't know the url.  I've tried:

freebie# svn update http://svn.freepascal.org/svn/lazarus/trunk
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# svn update http://svn.freepascal.org/svn/lazarus/trunk .
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# svn update . http://svn.freepascal.org/svn/lazarus/trunk
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# pwd
/usr/src/misc/Lazarus/2016-04-09/lazarus
freebie# cd ..
freebie# svn update http://svn.freepascal.org/svn/lazarus/trunk lazarus
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie# svn update lazarus http://svn.freepascal.org/svn/lazarus/trunk
svn: E205000: Try 'svn help update' for more information
svn: E205000: 'http://svn.freepascal.org/svn/lazarus/trunk' is not a local
path
freebie#
svn update with url is something of old svn command, e.g. not supported anymore afaik.

In case directory /usr/src/misc/Lazarus/2016-04-09/lazarus contains your svn checkout then try:
Code: [Select]
cd /usr/src/misc/Lazarus/2016-04-09/lazarus
svn update

fwiw: the wiki also does not mention updating with providing an url.

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Re: Type conversion errors, mucking around
« Reply #6 on: April 15, 2016, 06:40:00 am »
No, I haven't done a checkout, I downloaded a tarball with wget and I want to update that.  Where does svn store the URL?  Anyway to put a url in there and trick it into updating from it?

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Type conversion errors, mucking around
« Reply #7 on: April 15, 2016, 06:50:12 am »
No, I haven't done a checkout, I downloaded a tarball with wget and I want to update that.
You can't.

Quote
Where does svn store the URL?
In the .svn directories that are automatically created for you when you do a checkout with svn.

Quote
Anyway to put a url in there and trick it into updating from it?
No.

You have two options:
1) download an updated (newer) tarball from the same location you got the previous one (they are updates on a regular base)
2) have enough room on your harddisk to do a svn checkout (svn co http://svn.freepascal.org/svn/lazarus/trunk lazarus)

The latter (number 2), does require you to download _all_ the sources once again, but if you leave those sources on your hard disk you can use svn update to _only_ fetch the latest changes from the last time you did an update (e.g. that saves you _a lot_ of bandwidth for the future).

If you are regularly in need of having the latest changes for lazarus, then number 2 is the better option on the long run.

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Re: Type conversion errors, mucking around
« Reply #8 on: April 15, 2016, 04:33:32 pm »
I felt like playing around I guess.  I made a new directory with today's date, went into it and did svn co <url>.  It died quickly but left a .svn directory.  So I copied that directory into where my tarball is extracted, CDed into it.  Did svn update and it's running.

The treasure I found in the .svn dir is an Sqlite database which has the URL in it.  Turned to SQL by Midnight Commander's file viewer (lines truncated to terminal width) I see:

PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE REPOSITORY (   id INTEGER PRIMARY KEY AUTOINCREMENT,   root  TEX
INSERT INTO "REPOSITORY" VALUES(1,'http://svn.freepascal.org/svn/lazarus','40
CREATE TABLE WCROOT (   id  INTEGER PRIMARY KEY AUTOINCREMENT,   local_abspat
INSERT INTO "WCROOT" VALUES(1,NULL);
CREATE TABLE PRISTINE (   checksum  TEXT NOT NULL PRIMARY KEY,   compression
CREATE TABLE ACTUAL_NODE (   wc_id  INTEGER NOT NULL REFERENCES WCROOT (id),
CREATE TABLE LOCK (   repos_id  INTEGER NOT NULL REFERENCES REPOSITORY (id),
CREATE TABLE WORK_QUEUE (   id  INTEGER PRIMARY KEY AUTOINCREMENT,   work  BL
CREATE TABLE WC_LOCK (   wc_id  INTEGER NOT NULL  REFERENCES WCROOT (id),   l
CREATE TABLE NODES (   wc_id  INTEGER NOT NULL REFERENCES WCROOT (id),   loca
INSERT INTO "NODES" VALUES(1,'',0,NULL,1,'trunk',52201,'incomplete',NULL,NULL
CREATE TABLE EXTERNALS (   wc_id  INTEGER NOT NULL REFERENCES WCROOT (id),
ANALYZE sqlite_master;
INSERT INTO "sqlite_stat1" VALUES('NODES','sqlite_autoindex_NODES_1','8000 80
INSERT INTO "sqlite_stat1" VALUES('NODES','I_NODES_PARENT','8000 8000 10 2 1'
INSERT INTO "sqlite_stat1" VALUES('NODES','I_NODES_MOVED','8000 8000 1 1');
INSERT INTO "sqlite_stat1" VALUES('ACTUAL_NODE','sqlite_autoindex_ACTUAL_NODE
INSERT INTO "sqlite_stat1" VALUES('ACTUAL_NODE','I_ACTUAL_PARENT','8000 8000
INSERT INTO "sqlite_stat1" VALUES('LOCK','sqlite_autoindex_LOCK_1','100 100 1
INSERT INTO "sqlite_stat1" VALUES('WC_LOCK','sqlite_autoindex_WC_LOCK_1','100
DELETE FROM sqlite_sequence;
INSERT INTO "sqlite_sequence" VALUES('REPOSITORY',1);
INSERT INTO "sqlite_sequence" VALUES('WCROOT',1);
CREATE INDEX I_UUID ON REPOSITORY (uuid);
CREATE INDEX I_ROOT ON REPOSITORY (root);
CREATE UNIQUE INDEX I_LOCAL_ABSPATH ON WCROOT (local_abspath);
CREATE INDEX I_PRISTINE_MD5 ON PRISTINE (md5_checksum);
CREATE UNIQUE INDEX I_ACTUAL_PARENT ON ACTUAL_NODE (wc_id, parent_relpath,
CREATE UNIQUE INDEX I_NODES_PARENT ON NODES (wc_id, parent_relpath,
CREATE UNIQUE INDEX I_NODES_MOVED ON NODES (wc_id, moved_to, op_depth);
CREATE VIEW NODES_CURRENT AS   SELECT * FROM nodes AS n     WHERE op_depth =
CREATE VIEW NODES_BASE AS   SELECT * FROM nodes   WHERE op_depth = 0;
CREATE TRIGGER nodes_insert_trigger AFTER INSERT ON nodes WHEN NEW.checksum I
CREATE TRIGGER nodes_delete_trigger AFTER DELETE ON nodes WHEN OLD.checksum I
CREATE TRIGGER nodes_update_checksum_trigger AFTER UPDATE OF checksum ON node
CREATE UNIQUE INDEX I_EXTERNALS_DEFINED ON EXTERNALS (wc_id,
COMMIT;

I've used git and rsynch, don't have much experience with svn.  At least using update I have some confidence that when it gets interrupted due to my connection being imperfect an update should mostly resume.  The database doesn't seem to be growing.  Meanwhile back to the real problem, updating will probably take hours if not days.  It seems to be mostly doing adds so I'm not sure I accomplished anything over using co.
« Last Edit: April 15, 2016, 04:46:12 pm by ab1jx »

ab1jx

  • New Member
  • *
  • Posts: 23
    • Just some photos on Nikonians
Re: Type conversion errors, mucking around
« Reply #9 on: April 15, 2016, 06:34:33 pm »
OK, different hardware: my laptop, a Dell Latitude D530 which I've been told is 64-bit capable.  Installed FPC 3.0.0 using my copied OpenBSD port, built Lazarus 1.6 from the tarball, no problem at all.

This machine is a Dell Optiplex GX270 built in 2002, single 3 GHZ Pentium 4 with hyperthreading.  Laptop is dual core.  Since all the type conversion errors involved LongInts I'm wondering if it's a 32/64 bit CPU issue.  I'm running the same 32-bit OpenBSD 5.7 on both.

 

TinyPortal © 2005-2018