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 ?
?
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
On Wed, 26 Mar 2014 10:59:52 +0100
Mattias Gaertner nc-gaert...@netcologne.de 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
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 09:10:09 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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.
(either the
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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 mich...@freepascal.org wrote:
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
So, FPC uses a system call to get the correct
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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 mich...@freepascal.org wrote:
On Tue, 25 Mar 2014, Mattias Gaertner wrote:
So, FPC
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 11:25:19 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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.
On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 12:07:01 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 13:37:32 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
[...]
But I am arguing that when passing filenames/paths to other tools
(including the compiler), you should always specify full filenames.
The IDE
On Wed, 26 Mar 2014 14:31:19 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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
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
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
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 mich...@freepascal.org wrote:
[...]
But I am arguing that when passing filenames/paths to other tools
(including the
On Wed, 26 Mar 2014 15:19:29 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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(
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 debug
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:19:29 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
[...]
I tested, and indeed:
# include_directories
.ascii ../../tmp/link\000
I think this is an error in FPC, because the linker file contains
On Wed, 26 Mar 2014, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 15:33:38 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
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, 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, because it
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
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
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
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
@ 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)
# --
#
#
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
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 fi...@hotmail.com:
@ Fabio Luis Girardi :
Here my working *fpc.cfg*
_
#
# Config file generated by fpcmkcfg on
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
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
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
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
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 to
a
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
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
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
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
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 mar...@stack.nl:
FYI:
Free Pascal is candidate for SF project of the month april, up against
strong candidates as subversion for windows (the server, not
On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org 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
On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
[...]
The compiler does not do anything special: it determines its current
working directory using the RTL, meaning it gets the resolved current
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 an
On Wed, 26 Mar 2014 23:19:57 +0100
Tomas Hajny xhaj...@hajny.biz wrote:
On 26 Mar 14, at 23:05, Mattias Gaertner wrote:
On Wed, 26 Mar 2014 18:47:06 +0100 (CET)
Michael Van Canneyt mich...@freepascal.org wrote:
[...]
The compiler does not do anything special: it determines its
50 matches
Mail list logo
