View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015221||FPC||Compiler||public||2009-11-30 18:46||2014-06-17 15:28|
|Reporter||Phil||Assigned To||Jonas Maebe|
|Platform||Intel||OS||Windows / OS X|
|Summary||0015221: Checksum issue|
|Description||Please see this Lazarus bug report:|
|Tags||No tags attached.|
|Fixed in Revision|
This can happen in two situations:
a) a routine is declared as external in the implementation of a unit, but not in the interface. Solution: add the full external declaration to the interface
b) a unit calls a routine that's declared as "inline" in another unit before the implementation of that routine has been parsed. Solution: remove the "inline" modifier, change the dependency graph so that the implementation of all inline routines have been parsed before they are called, or compile the units with -Ur.
The -Ur option marks a unit as "release", which means that the compiler will never try to recompile it.
I don't any use of inline or external directives in the units that are being compiled. So there must be a (c) case?
||Possibly, but the solution is the same: compile with -Ur. That's also what we do with all units that are distributed with FPC releases.|
Jonas, I haven't found much information on what the ramifications are in using -Ur. If a user installs a different version of Lazarus or FPC, are there situations where the package won't be recompiled?
This is a package under development. I'm not sure that -Ur was intended for that.
-Ur means that
a) regardless of checksum changes in units used by the current one
b) regardless of newer source files than those from which the unit was compiled
c) regardless of any other reason why the compiler might normally want to recompile a previously compiled unit
the compiler will always use the previously compiled .ppu/.o file and not try to recompile it under any circumstances.
So if you want to recompile a unit that has been compiled with -Ur, you have to delete its .ppu/.o files first.
Hmm, I don't think that will be a suitable solution for this package.
Any idea why this does not occur on PowerPC?
> Any idea why this does not occur on PowerPC?
|2009-11-30 18:46||Phil||New Issue|
|2009-11-30 18:58||Jonas Maebe||Status||new => resolved|
|2009-11-30 18:58||Jonas Maebe||Resolution||open => no change required|
|2009-11-30 18:58||Jonas Maebe||Assigned To||=> Jonas Maebe|
|2009-11-30 18:58||Jonas Maebe||Note Added: 0032604|
|2009-11-30 19:49||Phil||Status||resolved => feedback|
|2009-11-30 19:49||Phil||Resolution||no change required => reopened|
|2009-11-30 19:49||Phil||Note Added: 0032605|
|2009-11-30 19:59||Jonas Maebe||Status||feedback => resolved|
|2009-11-30 19:59||Jonas Maebe||Resolution||reopened => no change required|
|2009-11-30 19:59||Jonas Maebe||Note Added: 0032606|
|2009-11-30 23:06||Phil||Status||resolved => feedback|
|2009-11-30 23:06||Phil||Resolution||no change required => reopened|
|2009-11-30 23:06||Phil||Note Added: 0032612|
|2009-11-30 23:30||Jonas Maebe||Note Added: 0032613|
|2009-11-30 23:30||Jonas Maebe||Assigned To||Jonas Maebe =>|
|2009-11-30 23:30||Jonas Maebe||Status||feedback => new|
|2009-12-01 01:36||Phil||Note Added: 0032617|
|2009-12-01 11:24||Jonas Maebe||Note Added: 0032627|
|2014-06-17 15:28||Jonas Maebe||Relationship added||duplicate of 0024121|
|2014-06-17 15:28||Jonas Maebe||Status||new => resolved|
|2014-06-17 15:28||Jonas Maebe||Resolution||reopened => duplicate|
|2014-06-17 15:28||Jonas Maebe||Assigned To||=> Jonas Maebe|