fpc would look for the compiler in the same directory as it is. I believe
your fpc resides in /usr/bin or /usr/local/bin
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/How-to-install-another-version-of-fpc-tp5672688p5675207.html
Sent from the Free Pascal - Gener
2012/4/29 Mattias Gaertner :
>> I tried this but then it seems it would try to use what is configured
>> in "Build Lazarus"
> I fixed that. Please test.
Now it works, now just setting the target OS is sufficient :-)
Thank you!
Bernd
___
fpc-pascal mai
On Sun, 29 Apr 2012 15:27:47 +0200
Bernd wrote:
> 2012/4/29 Mattias Gaertner :
>
> > You don't need to set the LCLWidgetType here because win32 is the
> > default for TargetOS win32.
>
> I tried this but then it seems it would try to use what is configured
> in "Build Lazarus" which is set to G
Am 29.04.2012 17:50, schrieb Thomas Schatzl:
> Hi,
>
> On Sun, 2012-04-29 at 17:38 +0200, Florian Klämpfl wrote:
>> Am 29.04.2012 17:34, schrieb Thomas Schatzl:
>>> Hi
florian@ubuntu32:~$ ldd ./test
libfprtl-2.7.1.so =>
/home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7,
Interested people might want to have a look at
http://bugs.freepascal.org/view.php?id=12492
there are iirc still unprocessed patches in that report.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
Hi,
On Sun, 2012-04-29 at 17:38 +0200, Florian Klämpfl wrote:
> Am 29.04.2012 17:34, schrieb Thomas Schatzl:
> > Hi
> >> florian@ubuntu32:~$ ldd ./test
> >> libfprtl-2.7.1.so =>
> >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7,
> >
> > Actually, this output shows the bug already
Am 29.04.2012 17:34, schrieb Thomas Schatzl:
> Hi
> On Sun, 2012-04-29 at 15:50 +0200, Florian Klämpfl wrote:
>> Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior:
>>> If you deploy one executable, ok, but if you want to create a handfull
>>> of executables (following unix logic of many small
Hi
On Sun, 2012-04-29 at 15:50 +0200, Florian Klämpfl wrote:
> Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior:
> > If you deploy one executable, ok, but if you want to create a handfull
> > of executables (following unix logic of many small programs) then you
> > have a problem.
>
> Indee
In our previous episode, Bernd said:
> an fpc checkout from the 2.6 fixes branch
> a lazarus checkout from the trunk
>
> For normal compiling (not cross) after updating everything from svn I
> usually just use
>
> in the fpc directory
> make clean all
> sudo make install
A small warning, and po
In our previous episode, Florian Kl?mpfl said:
> > make sysutils/runtime etc an external loadable library and we are
> > going to see FPC generate similar sized executables for similarly
> > sized programs.
>
> It makes them look smaller but their footprint is actually larger so
> this is exactly
Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior:
> If you deploy one executable, ok, but if you want to create a handfull
> of executables (following unix logic of many small programs) then you
> have a problem.
Indeed, but I don't think this is the way FPC programs are typically used.
>
2012/4/29 Mattias Gaertner :
> You don't need to set the LCLWidgetType here because win32 is the
> default for TargetOS win32.
I tried this but then it seems it would try to use what is configured
in "Build Lazarus" which is set to GTK2 on my machine. When I try to
run the resulting exe in wine t
On 29 Apr 2012, at 15:13, Jorge Aldo G. de F. Junior wrote:
> If you deploy one executable, ok, but if you want to create a handfull
> of executables (following unix logic of many small programs) then you
> have a problem.
You certainly do end up with larger executables. Whether or not this is a
On Sun, 29 Apr 2012 15:01:12 +0200
Bernd wrote:
> Hi,
>
> I just thought I kill some time investigating cross compiling from
> i386-linux to i386-win32 and hada look at the wiki page
> http://wiki.freepascal.org/Cross_compiling
>
> It seems there is some important thing missing, right at the be
If you deploy one executable, ok, but if you want to create a handfull
of executables (following unix logic of many small programs) then you
have a problem.
EVERY executable will have the same code again again again, i think
libraries have been created to address exactly this issue.
about the lib
Jonas Maebe wrote:
On 29 Apr 2012, at 14:23, Jorge Aldo G. de F. Junior wrote:
What would be usefull is to move the loads of code stored in
sysutils/runtime into a dll/so.
That's mainly useful if the external API of the RTL will ever stabilize, which
is certainly not the case today. Otherwis
Hi,
I just thought I kill some time investigating cross compiling from
i386-linux to i386-win32 and hada look at the wiki page
http://wiki.freepascal.org/Cross_compiling
It seems there is some important thing missing, right at the beginning
but I don't know enough about fpcmake to extend the arti
Am 29.04.2012 14:23, schrieb Jorge Aldo G. de F. Junior:
> What would be usefull is to move the loads of code stored in
> sysutils/runtime into a dll/so.
>
> thats what makes C code look "smaller", theres a nice libc (and
> others) there that groups mostly used functions into a single
> instance,
On 29 Apr 2012, at 14:23, Jorge Aldo G. de F. Junior wrote:
> What would be usefull is to move the loads of code stored in
> sysutils/runtime into a dll/so.
That's mainly useful if the external API of the RTL will ever stabilize, which
is certainly not the case today. Otherwise you create a dyn
What would be usefull is to move the loads of code stored in
sysutils/runtime into a dll/so.
thats what makes C code look "smaller", theres a nice libc (and
others) there that groups mostly used functions into a single
instance, while in pascal every executable replicates the very same
code for ea
Hi list,
I'm working on improving bufdataset testing in the dbtestframework,
documenting the framework a bit more. (Attached FYI my current version
of the readme; comments welcome as always).
I found this in sqldbtoolsunit.pas:
destructor TSQLDBConnector.Destroy;
...
if assigned(FTransaction) t
On 29 Apr 2012, at 12:22, Florian Klämpfl wrote:
> Spent more man power into optimizer development, though some
> optimizations are hard in pascal because we assume stricter aliasing
> rules and because we don't have a volatile keyword.
At least as far as our current optimizers are concerned, no
Am 29.04.2012 12:13, schrieb ik:
> Let's take simple program:
>
> pascal code
>
> program hello;
>
> begin
> writeln('Hello World');
> end.
>
> - pascal code
>
> vs c code:
>
> -- c code -
> #include
>
> int main(int argc, char ** argv) {
> printf("Hello World
Am 29.04.2012 11:40, schrieb ik:
> Hello,
>
> Here is something that I'm asking without really know anything about
> the subject, so please bear with me.
>
> I'ved asked few places that works with Pascal (Delphi and FPC), why
> does they use C as the infrastructure, and they all say that there is
On Sun, Apr 29, 2012 at 12:58, Reinier Olislagers
wrote:
> On 29-4-2012 11:40, ik wrote:
>> Hello,
>>
>> Here is something that I'm asking without really know anything about
>> the subject, so please bear with me.
>>
>> I'ved asked few places that works with Pascal (Delphi and FPC), why
>> does th
On 29-4-2012 11:40, ik wrote:
> Hello,
>
> Here is something that I'm asking without really know anything about
> the subject, so please bear with me.
>
> I'ved asked few places that works with Pascal (Delphi and FPC), why
> does they use C as the infrastructure, and they all say that there is
>
Hello,
Here is something that I'm asking without really know anything about
the subject, so please bear with me.
I'ved asked few places that works with Pascal (Delphi and FPC), why
does they use C as the infrastructure, and they all say that there is
not even one Pascal compiler that makes the co
27 matches
Mail list logo
