On Wed, 26 Mar 2014 23:19:57 +0100
"Tomas Hajny" wrote:
> On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
> > On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
> > Michael Van Canneyt wrote:
> >
> > >[...]
> > > The compiler does not do anything special: it determines its current
> > > working director
On 26 Mar 2014, at 23:15, fredvs wrote:
>
> Also, delete all the *.ppu and *.o of previous compile.
FWIW: Removing all of them when you get weird errors always does the trick
here. You can probably count yourself lucky as I once had a project with an
outdated .o file that *did* link. Took me a
On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
> On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
> Michael Van Canneyt wrote:
>
> >[...]
> > The compiler does not do anything special: it determines its current
> > working directory using the RTL, meaning it gets the resolved current
> > working direc
> No problem... what's your fpc version? I'll compare with the right version
of FPC here.
Hum, now it compiles the library using same fpc.cfg with fpc 2.6.2. and
2.7.1 perfectly (the size of library is > with fpc 2.7.1).
It seems to me that the trick was to add lot of -Fu and -Fi search-paths for
On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> The compiler does not do anything special: it determines its current
> working directory using the RTL, meaning it gets the resolved current
> working directory.
I described the situation from a user's pov.
Somewhere
Done! (y)
https://sourceforge.net/p/potm/discussion/vote/thread/c38203c8/#f28e/22a0
2014-03-26 17:44 GMT-03:00 Marco van de Voort :
>
> FYI:
>
> Free Pascal is candidate for SF project of the month april, up against
> strong candidates as subversion for windows (the server, not tortoise) and
> s
On Wed, 26 Mar 2014, Jonas Maebe wrote:
On 26/03/14 19:07, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Jonas Maebe wrote:
Specifying the directories in a
relative way means that you can easily copy over a debug binary and
all related source code from one system to another (or move thi
FYI:
Free Pascal is candidate for SF project of the month april, up against
strong candidates as subversion for windows (the server, not tortoise) and
smplayer.
Note that you need a SF login to vote:
https://sourceforge.net/p/potm/discussion/vote/thread/c38203c8/
Marco
First the good news:
this new release of FP.EXE has removed previous errors
and it seems that GDB works. Thank you for your work.
Now the bad news:
1.
When I press "ALT+0" to get window list I get this error
regardless if a file(s) are opened or not:
Runtime error 219 at $4868
$4868 F
On 26/03/14 19:07, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Jonas Maebe wrote:
Specifying the directories in a
relative way means that you can easily copy over a debug binary and
all related source code from one system to another (or move things
around) without breaking anything. For t
Running fppkg in my source dir gives me a crash. Please see below.
>>fppkg build
An unhandled exception occurred at $00010004FA3E :
EProcess : Failed to execute C:lazarusfpc2.6.2bini386-win32fpc.exe
-iVTPTO : 2
$00010004FA3E
$000100013E42
$000100018F7A
$00010001
Hi Michael,
I have never used fppkg this way. Can you explain how I should use it?
Regards, Darius
On Mar 26, 2014, at 6:09 PM, Michael Van Canneyt wrote:
>
>
> On Wed, 26 Mar 2014, Darius Blaszyk wrote:
>
>> Hi,
>> I'm playing again with fpmake and I struck an issue with it. Probably due t
On Wed, 26 Mar 2014, Michael Van Canneyt wrote:
The problem is easy to reproduce, as Mattias demonstrated.
During debugging, Lazarus consistently opens a file twice (or doesn't find it
at all) when symlinks are used in the path to the project file, because there
is a mismatch
between the r
On Wed, 26 Mar 2014, Jonas Maebe wrote:
On 26/03/14 17:23, Michael Van Canneyt wrote:
At the very least I think that we should be consistent and use the same
filenames in link script and debug info ?
How directories are stored in the debug info is generally defined by the
debug info format
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
Here is a summarize so far:
When the compiler is started in a directory with a symlink, the
directory is resolved and used for error messages and debug info.
All other directories are not resolved.
If you want fpc to use only unresolved paths, you
No problem... what's your fpc version? I'll compare with the right version
of FPC here.
2014-03-26 14:17 GMT-03:00 fredvs :
> @ Fabio Luis Girardi :
>
> Here my working *fpc.cfg*
> _
> #
> # Config file generated by fpcmkcfg on 5-3-14 - 21:
On 26/03/14 17:23, Michael Van Canneyt wrote:
At the very least I think that we should be consistent and use the same
filenames in link script and debug info ?
How directories are stored in the debug info is generally defined by the
debug info format itself. E.g. the DWARF standard explicitly
@ Fabio Luis Girardi :
Here my working *fpc.cfg*
_
#
# Config file generated by fpcmkcfg on 5-3-14 - 21:58:27
# Example fpc.cfg for Free Pascal Compiler
#
# --
# Defines (preprocessor)
# --
#
# nested
On Wed, 26 Mar 2014, Darius Blaszyk wrote:
Hi,
I'm playing again with fpmake and I struck an issue with it. Probably due to a
wrong setup of my packages, but I cannot find a way to resolve it. I keep on
getting the
following error:
Warning: Target XXX of package YYY depends on another pack
>> You recompiled the FPC? Or simple change of fpc.cfg options solves your
problem?
Oops, sorry for the delay.
I only change fpc.cfg options and it solves the problem...
Hum, im really sorry but i do not know what changes do the trick. (i did not
save the old fpc.cfg-not-working, so, i cannot c
Hi,
I'm playing again with fpmake and I struck an issue with it. Probably
due to a wrong setup of my packages, but I cannot find a way to resolve
it. I keep on getting the following error:
Warning: Target XXX of package YYY depends on another package (ZZZ).
These kind of dependencies are not p
On Wed, 26 Mar 2014, Tomas Hajny wrote:
On Wed, March 26, 2014 15:35, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Tomas Hajny wrote:
The two should at least match; and you will not be surprised to hear
that
I think the linker file is correct :)
.
.
It makes no sense to use absolute pat
On Wed, March 26, 2014 15:35, Michael Van Canneyt wrote:
> On Wed, 26 Mar 2014, Tomas Hajny wrote:
>>> The two should at least match; and you will not be surprised to hear
>>> that
>>> I think the linker file is correct :)
>> .
>> .
>>
>> It makes no sense to use absolute paths in debug information
Here is a summarize so far:
When the compiler is started in a directory with a symlink, the
directory is resolved and used for error messages and debug info.
All other directories are not resolved.
If you want fpc to use only unresolved paths, you can start fpc in
a directory without sources. But
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt wrote:
[...]
So ? You just need to check the inode.
Is there a function to list all files pointing to an inode?
Actually, you just need to know if 2 filenames point to the same ino
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:19:29 +0100 (CET)
Michael Van Canneyt wrote:
[...]
I tested, and indeed:
# include_directories
.ascii "../../tmp/link\000"
I think this is an error in FPC, because the linker file contains full paths:
INPUT(
/u
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> >> So ? You just need to check the inode.
> >
> > Is there a function to list all files pointing to an inode?
>
> Actually, you just need to know if 2 filenames point to the same inode.
And what 2 files should I check
In our previous episode, Tomas Hajny said:
> > The two should at least match; and you will not be surprised to hear that
> > I think the linker file is correct :)
> .
> .
>
> It makes no sense to use absolute paths in debug information, because it
> would make distribution of units compiled with
On Wed, 26 Mar 2014 15:19:29 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> I tested, and indeed:
>
> # include_directories
> .ascii "../../tmp/link\000"
>
> I think this is an error in FPC, because the linker file contains full paths:
>
> INPUT(
> /usr/local/lib/fpc/2.7.1/units/x86
On Wed, 26 Mar 2014, Tomas Hajny wrote:
The two should at least match; and you will not be surprised to hear that
I think the linker file is correct :)
.
.
It makes no sense to use absolute paths in debug information, because it
would make distribution of units compiled with debug informatio
On Wed, March 26, 2014 15:19, Michael Van Canneyt wrote:
>
>
> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>
>> On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
>> Michael Van Canneyt wrote:
>>
>>> [...]
>>> But I am arguing that when passing filenames/paths to other tools
>>> (including the compiler), y
On 26/03/2014 14:30, Tomas Hajny wrote:
It makes no sense to use absolute paths in debug information, because it
would make distribution of units compiled with debug information to other
machines impossible (or more precisely - it would be possible to
distribute them, but debugging would not work
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 14:31:19 +0100 (CET)
[...]
Just add a syntax error to unit1.pas and compile once in /tmp/link and
once outside. You see once the physical directory and once the
logical.
So ? You just need to check the inode.
Is there a fu
On Wed, 26 Mar 2014 14:31:19 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > What problem do they have? /tmp/link is a valid file name.
>
> Only because it is a full path. Then it doesn't matter whether you resolve or
> not.
>
> But things like ../link may end up wildly on wildly different p
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
Michael Van Canneyt wrote:
[...]
But I am arguing that when passing filenames/paths to other tools
(including the compiler), you should always specify full filenames.
The IDE passes all search paths as f
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
[...]
You seem to think tcsh-specific behaviour is the correct way to do
things. ;)
Well, actually I don't think in such terms. I
On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> But I am arguing that when passing filenames/paths to other tools
> (including the compiler), you should always specify full filenames.
The IDE passes all search paths as full file paths, especially no
'..'. No problem
On 25 Mar 2014, at 07:13, Xiangrong Fang wrote:
2. How can I tell the compiler NOT to generate EDivideByZero or any
similar
stuff, but just return the IEEE Infinity NegInfinity or Nan
accordingly? I
know that they are defined in the math unit.
http://www.freepascal.org/docs-html/rtl/math/
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt wrote:
> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>[...]
> > You seem to think tcsh-specific behaviour is the correct way to do
> > things. ;)
>
> Well, actually I don't think in such terms. I think that the system is right.
> And
This enables a process eg an .exe to be run without using cmd (unlike exec)
and if so, I'd like to use it. Can anyone provide one or two simple example
lines for using this, on windows.
Below is definition in sysutils help. It explains what path & comline do,
but doesn't really explain why one wou
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt wrote:
[...]
Keep in mind that /tmp/link/unit1.pas and /tmp/orig/uni1.pas must be
treated as two different files and within one project you must use
only one of them.
There you are w
On Wed, 26 Mar 2014, Tomas Hajny wrote:
On Wed, March 26, 2014 11:25, Michael Van Canneyt wrote:
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt wrote:
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
So, FPC uses a system call to ge
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > Keep in mind that /tmp/link/unit1.pas and /tmp/orig/uni1.pas must be
> > treated as two different files and within one project you must use
> > only one of them.
>
> There you are wrong. They must be treated as the sa
On Wed, March 26, 2014 11:25, Michael Van Canneyt wrote:
> On Wed, 26 Mar 2014, Mattias Gaertner wrote:
>> On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
>> Michael Van Canneyt wrote:
>>> On Tue, 25 Mar 2014, Mattias Gaertner wrote:
>>>
>
> So, FPC uses a system call to get the correct (resolved
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt wrote:
[...]
AFAIK the PWD is the official thing and used by other console tools as
well. For example when I compile a file with gcc in a symlinked
directory it creates debugging info
In our previous episode, Mattias Gaertner said:
> >
> > It's a hack ?
>
> AFAIK the PWD is the official thing and used by other console tools as
> well.
afaik:
1) it is an official thing only of the shell, not the "system".
2) it assumes that any program doesn't change paths inbetween.
(eith
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt wrote:
>[...]
> > AFAIK the PWD is the official thing and used by other console tools as
> > well. For example when I compile a file with gcc in a symlinked
> > directory it creates debugging info with the unresolved file name.
>
>
>
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt wrote:
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
So, FPC uses a system call to get the correct (resolved) CWD directory.
This is the only guaranteed mechanism.
What's wrong wi
On Wed, 26 Mar 2014 10:59:52 +0100
Mattias Gaertner wrote:
>[...]
> But SetCurrentDir does not work. It seems to resolve directories. The
> documentation does not mention this behavior. Is this by design?
The setcwd of C does the same, so I guess it is by design.
It should be documented.
Matti
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt wrote:
>
>
> On Tue, 25 Mar 2014, Mattias Gaertner wrote:
>
> >>
> >> So, FPC uses a system call to get the correct (resolved) CWD directory.
> >> This is the only guaranteed mechanism.
> >
> > What's wrong with this:
> > if GetEnvi
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
So, FPC uses a system call to get the correct (resolved) CWD directory.
This is the only guaranteed mechanism.
What's wrong with this:
if GetEnvironmentVariable('PWD')<>'' then
SetCurrentDir(GetEnvironmentVariable('PWD'));
It's a hack ?
?
51 matches
Mail list logo
