Additional source-link:
https://gitlab.gnome.org/rburton/gdk-pixbuf/-/blob/GTK_MULTIHEAD_MERGEPOINT_28_03_02/gtk/fnmatch.c#L61
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
AFAIK, the GTK fnmatch can be found here:
https://codebrowser.dev/gtk/include/fnmatch.h.html
But I am 100% in favour of only using fnmatch from glibc !
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailm
The mORMot[1] sources could give you some info.
During runtime, it patches the exe-memory to redirect function calls.
Hard part was to get around the W^X memory protection on some BSD's.
Look at:
procedure PatchCode(Old,New: pointer; Size: integer; Backup: pointer;
inside SynCommons.pas
functio
Looks good. Thanks. My conclusion: we need more of this !
No kidding. This XML output is very useful. And, naturally, I would like
to ask for more.
If more is given, the use of a scheme would make it very convenient
(easy) to add new content and to read this new content.
But anyhow, this output
Hello,
As a follow-up on a Lazarus feature request.
Among other applications, Lazarus uses some hard-coded list that
represent FPC features. Like supported MCU and boards. It would be
(much) more convenient to parse the FPC output itself to supply this
info. And that could be made easy by usi
As there is (hopefully) more embedded and freertos coming to FPC trunk
soon, I would like to ask for a feature.
Would it be possible to emit the -Wp definition ?
And perhaps also the -Cp definition ?
Using embedded-freertos now requires me to use a -Wp setting and a
manual definition of this -
Naturally, fpcupdeluxe is a tool that should/could also be hosted in
this repo. I am not the owner, just a maintainer.
Github makes cooperated maintenance of sources and tools very easy.
Thanks for your thoughts.
Alfred.
___
fpc-devel maillist
Hello to all,
As you might know, I am the maintainer of fpcupdeluxe.
Its a tool to install FPC and Lazarus. And to install cross-compilers.
Intro.
As part of fpcupdeluxe, binutils (and libs) are created/hosted to be
able to cross-compile from various systems.
E.g. for Windows:
https://github.
Dear All,
Looking at t_linux.pas, this code is common (also for other system
files):
if (isdll) then
begin
Add('INPUT(');
Add(sysrootpath+info.DynamicLinker);
Add(')');
end;
And also:
if libraryadded and not(linklibc) and not(isdll) and
(tf_section_threadvars in target_info.f
I just tested on GhostBSD (FreeBSD12).
Trunk from today compiled out-of-the-box.
With available FPC 3.0.4 bootstrapper.
ld -v shows
GNU ld (GNU Binutils) 2.32
Command:
Executing: gmake --jobs=1
PP=/usr/home/superdad/fpcupdtunk/fpcbootstrap/ppcx64
FPCMAKE=/usr/home/superdad/fpcupdtunk/fpc/bin
Hello,
Would it be possible to add a macro definition (in trunk) to indicate
that attributes are supported ?
E.g. FPC_HAS_CUSTOMATTRIBUTES
Thanks.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/
Hello,
When running (on Windows) "fppkg.exe listsettings", the output shows
some global defaults for packages.
As maintainer of fpcupdeluxe, I am in favour of isolating different
installs of FPC (and Lazarus).
Would it be possible to add (feature request) a local fppkg.cfg (like
fpc.cgf) tha
Thanks for the advice.
The glue has already been used by me, including glue for the
FPC-makefiles. And some glue for Lazarus.
My question was more meant to be a fundamental one about the
organization of code.
Embedded is now a very viable target for FPC.
MCU's become powerful enough to be eas
Hello,
Intro.
After a long period of using C for writing firmware for Microchip PIC24
and PIC32, I am now switching hardware and software.
For future projects, I will use:
* the Atmel/Microchip ATSAM series; these are Cortex M-0/3/4 MPU.
* FPC for writing the firmware.
First tests show a succe
Thanks very much.
Program runs ... bit bloated, but the (embedded) work can continue !
-- Origineel bericht --
Van: "Michael Ring"
Aan: "Alfred"
Verzonden: 3-9-2018 13:11:11
Onderwerp: Re: [fpc-devel] Arm embedded on cortex m0
On first look is smells like Memo
Hello,
I have a problem using a TObject on arm embedded (cortex m0: an atmel
samd10x14).
It boils down to this:
2124 :
2124:b510 push{r4, lr}
2126:b08a subsp, #40; 0x28
2128:1c04 addsr4, r0, #0
212a:1c08 ad
Hello,
As maintainer of fpcup[deluxe], I have a fundamental question.
The original source of fpcup gives the possibility to build a
cross-compiler either with the compiler build from source or with the
bootstrapper that was used to build the compiler from source.
My question: am I correct in
Thanks for a very nice tool !
Small problem: AFAIK, the rtl.js is missing from SVN ?!
https://svn.freepascal.org/svn/projects/pas2js/trunk/src/rtl/___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list
The inc()s were needed due to alignment issues with the previous RTTI
implementation !
I indeed also wish for them to be not necessary anymore.
-- Origineel bericht --
Van: "Sven Barth"
Aan: "FPC developers' list"
Verzonden: 31-1-2017 14:56:19
Onderwerp: Re: [fpc-devel] Patch #31249 a
Good news !
I got in contact with Artur directly.
He will update me with aarch64 patches shortly (if and when his time
permits: couple of days) !
-- Origineel bericht --
Van: "Florian Klämpfl"
Aan: "Alfred" ; "FPC developers' list"
Verzonden: 22-
Hello,
I would like to know if there already any news about this ?
http://lists.freepascal.org/pipermail/fpc-devel/2016-August/037330.html
Thanks.___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/lis
Well, we're talking about two different things. In this interpretation,
NewPascal serves as some kind of FPC-experimental branch. Which is
nice,
and nothing to have against it.
But still, before merging anything to a master branch, there should be
a
way to review patches for obvious mistakes,
For a starter, if you should do something like:
if target_info.system in [system_i386_darwin,...] then...
instead of $IFDEF-ing HASUNIX. It's just a random idea, but because of
HASUNIX, your patch might have actually broken Win->Linux
crosscompiling... Plus
Also I haven't actually verified this
Follow up.
To enable cross from Windows towards Darwin, some changes in FPC were
needed.
They have been added into NewPascal, and can be found here:
https://github.com/newpascal/freepascal/commit/a99fe9054957d2c42c780c4d05e59c6fbda31621
Not meant to be 100% correct, but working.
Summary:
New
=30964
Thanks again, Alfred.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
in the same location, all goes well.
That why I patched the search-process. But this very rude patch only
took care of .o files.
I forgot about the .or files.
Trying new patches at the moment to no avail unfortunately.
-- Origineel bericht --
Van: "Sven Barth"
Aan: "
Please skip my previous mail.
I think I found the problem.
I had to patch osxcross-tools to work with FPC.
Now I need a new patch to include .or files !
Thanks again for the advice.
Will report back.
___
fpc-devel maillist - fpc-devel@lists.freepas
Thanks for this info and advice.
Sticking with Lazarus, I can see with "nm project1.or"
S FPC_RESSYMBOL
I can see with "nm project1.o"
U FPC_RESSYMBOL
The link-script includes project1.or and project1.o (naturally), so now
I am puzzled.
Any ideas ?
__
Follow up.
With the osxcross tools, cross-compilation of non-LCL programs from
Windows to Darwin is now successful.
When compiling with LCL, one final error keeps popping up:
Error: linker: Undefined symbols for architecture i386:
Error: linker: "FPC_RESSYMBOL", referenced from:
Debug: "FP
Has anybody any experience with using osxcross for cross-compiling from
Windows towards Darwin ?
https://github.com/tpoechtrager/osxcross
I am experimenting with it at the moment, using cygwin.
Osxcross binutils and MacSDK libs are ok on system.
Runs well, until an error when crosscompiling pp
@all
Please excuse me for misunderstanding !
I just build myself a new (cross)compiler with latest trunk.
I could successfully build latest trunk on the odroid itself.
Indeed, only a few minutes of work.
With the right knowledge, many things are easy.
Thanks for explaining.
Sorry for the troub
Thanks for clearing things up.
Too bad that building FPC trunk with trunk is not possible anymore.
I just build trunk rev 33894 native on the odroid-c2 without any
problems with a few weeks old trunk bootstrapper.
It would be nice (even if considered a happy coincidence), if the
possibility t
As I am expecting more fixes for aarch64 (see rev 33922 and bug
0030182), do you have any advice on how to proceed ?
For debugging purposes, I am in need of a native aarch64 on my
odroid-c2.
So, I need to be able to build latest trunk with a working/valid
bootstrapper on the odroid-c2 itself.
FPC revision 33895 introduced some changes that are behind a VER3_0
define.
This revision prevents the building of FPC trunk with a FPC 3.1.1
bootstrap compiler on an aarch64 system.
I do know that I should use a 3.0.0 bootstrapper to build trunk.
So, I am open for instructions on how to build
I would like to support the inclusion of interface RTTI.
Included a patch for this !
Thanks.
fpc300rtti.patch
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-d
@Steve,
Thanks for the update of the RTTI branch.
However, if I may ask one more thing, could the update be jumped to at
least 33597 ?!
This 33597 rev solves an important string problem (mantis #30082).
Thanks in advance for your efforts !
Alfred
Hello,
I would like to ask for an update of the interfacertti branch of FPC.
Included a patch with the changes for current trunk required for this
update.
Trunk has some changes that are important !
Thanks.
fpctrunkrtti.patch
Description: Binary data
_
1: ok; I will put a bootstrapper for aarch64 on fpcup github, for as
long as needed.
2a: you're right, there is a nice ppca64 (no exe) available !
2b: you talk about 3.0.0; I was not able to compile 3.0.0 for
aarch64-linux; am I mistaken ?
3: I will do so.___
After a successful install (with fpclazup) of FPC/Lazarus 64bit on an
Odroid-C2 running Arch Linux 64 bit, I have a few questions.
The initial (bootstrap) compiler was build by cross-compiling (trunk)
from Win32 to Aarch64.
Only trunk supports aarch64.
So, bootstrap version is 3.1.1. But trun
I was assuming that a goal (first quote: UTF16) would be accompanied by
(some sort of) a roadmap.
Perhaps I am wrong.
But, again, a comment on the remaining quotes would be welcome.
And also a comment on the use of {$mode delphiunicode}.
___
fpc-devel
Mmmm ... not that many answers ...
Let me try another question: does the link below correctly state the
current use and especially future of FPC / Lazarus ?
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
Especially (quotes):
* The goal of FPC project is to create a Delphi compat
Hello,
As happy user of mORMot (ORM framework) and FPC, I am encountering some
difficulties with the (more or less recent) string changes.
It's hard at the moment to get string handling for Delphi and FPC
lined-up.
So, I have this (hypothetical) question !
In the (near) future, I am still a
While trying to build trunk, I encountered the following peculiarity.
Building trunk with 3.0.0 : ok.
Building trunk with 3.0.1 (fixes ios) : not allowed due to wrong
version.
Building trunk with 3.0.2 (normal fixes) : not allowed due to wrong
version.
Is there a reason why you can only build
++ 1 !
We need to somehow clarify many things in this field. My next big
milestone is RTTI.Invoke method (I'd like to omit implementing this
:P). For example only in FPC dyn. array parameter is passed on stack
instead of by reference (in opposition to Delphi)... with small change
in r30870 fo
Done by Steve !
Thanks very much !!
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
I would like to ask for an update of the InterfaceRTTI branch, due to
some important fixes in FPC trunk !
Would that be possible ?
Thanks.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/f
Delphi XE8 (System.TypInfo):
TIntfMethodEntryTail = packed record
Kind: Byte; // 0=proc or 1=func
CC: TCallConv;
ParamCount: Byte;
{Params: array[1..ParamCount] of TIntfMethodParam;
ResultTypeName: string; // only if func
ResultType: PPTypeInfo; // only if Len(Name) > 0
: PTypeInfo;
StackSize: Word;
{$endif}
ParamCount: Byte;
{Params: array[0..ParamCount - 1] of TVmtMethodParam;}
end;
Alfred.
What exactly does the flag indicate.
1. Reading the structure as in typinfo woks
2. Register / Offset have meaningfull values instead of default 0 / 0
On my systems, current RTTI now in full use in combi with the mORMot ORM
!
Few questions remains:
1: Compiler flag
Question: Would it be possible to add a flag into this branch, so
programmes can automagically detect the presence of Interface RTTI ?
2: Alignment
Using brute force (due to lac
After your patch:
TestInterfaceRTTI.lpr (from today) runs fine without any change on ARM.
Removing / adding any alignment in TestInterfaceRTTI causes errors.
Strange !
I also have no clue.
No problem.
Can you check again with this diff applied?
If this doesn't work I'm a bit clueless.
Since I
I would like to report back about RTTI.
RTTI Branch was tested on RPi2 (ARMV7A, hardfloat), win32/64 (Win8.1),
Linux i386 (Arch VM) and Linux64 (Ubuntu VM).
I did encounter some new alignment issues again on ARM (see
checkMethod).
But some other alignment issues have vanished (see checkParam
on i386 still needed, but no changes
were needed for x86-64 !
Have still to test on ARM.
Thanks, Alfred.
Am 27.08.2015 um 17:28 schrieb Steve Hildebrandt:
Should be ok now.
Please Report back.
___
fpc-devel maillist - fpc-devel
Thanks for making the changes to the RTTI branch !
However, this branch does not compile, unless the following files are
added !
compiler\owomflib.pas
packages\mysql\src\mysql57dyn.pp
packages\winunits-base\src\shlwapi.pp
packages\fcl-web\src\base\httpprotocol.pp
packages\fcl-web\src\base\cgip
Hello to all,
Coming back from a long vacation, I saw today that there are some major
changes (trunk) made to ncgrtti.pas.
As you may perhaps know, I do have some interest in somewhat extended
(interface) rtti.
The initial extended rtti is saved in a separate branch. And working for
me !
ht
@vfclists
This was a regression ... should be fixed by now.
@florian
Importing should have been done !
However, this all started as a not-too-serious attempt by me to get
fpcup running again.
I must say its not easy to maintain/understand code without possibility
to consult the author.
Hello,
I got a message from "JuhaManninen" on the Lazarus forum:
http://forum.lazarus.freepascal.org/index.php/topic,27211.0.html?PHPSESSID=bf43911005bf788ab072b3d73d1bfb4f
http://forum.lazarus.freepascal.org/index.php/topic,27211.msg177117.html?PHPSESSID=bf43911005bf788ab072b3d73d1bfb4f#msg177
Hello,
I would like to inform you that the interfacertti branch contains the
wrong patch !
E.g for i386, it implements:
ti386paramanager.get_para_regoff
but it should be:
tcpuparamanager.get_para_regoff
This is valid for all implemented architectures (i386, X86_64, arm)
Correct patch (hopefu
Thanks very much for a very nice feature !!
I am testing (with the supplied demo) the Calendar APIs.
And run into error 204.
This (inside googleservice):
S:=TJSONObject(D).Get('kind','');
returns "calendar#calendarList"
This seems to result into a failure to get an objectclass at:
BC:=GoogleFact
Thanks for your answer !
To be honest, I do not know exactly what to do to solve this problem.
If I look at the source of TProcess, a lot of thing are done with the
parameters.
The parameters are parsed into a list. And again converted into a
PCharList.
And some info is lost during these conv
Hello to all.
While working on fpcup, I did encounter the following problem.
Fpcup has modules that implement automatic download and install of
packages.
One of these modules is indy.
Indy has a svn server that needs a username. No password is needed.
However, if a username is given to a comm
The RTTI branch is included with fpcup !
https://github.com/LongDirtyAnimAlf/Reiniero-fpcup/
See fpcup.ini. Getting FPC with the new RTTI is now as simple as:
fpcup --fpcURL="RTTI" --only="fpc"___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Everything works as expected now (my programs, as well as your recent
TestInterfaceRTTI.lpr), if
+if (vo_is_hidden_para in para.varoptions) and not
+ (vo_is_self in para.varoptions) then
+ continue;
is included in the ncgrtti.pas patc
Thanks for your answer Steve !
But now I have the problem that I cannot parse the RTTI anymore.
I fail to get the logic:
This is written as paracount:
current_asmdata.asmlists[al_rtti].concat(Tai_const.Create_8bit(def.maxparacount
+ 1));
This is used for the param-loop:
for k:=0 to def.paras.
Please do include me !
I have included the rtti-patch (diff) based on the current (today :
30566) trunk.
Its nothing else than the patch-set from Steve, but with one change:
for k:=0 to def.paras.count-1 do
begin
para:=tparavarsym(def.paras[k]);
{note from Alf:}
{this was in the f
Hello again to all,
I am enjoying variant late binding AND interface RTTI for a while now !
Thanks again !
As far as I know, the patch for RTTI has not yet been included in trunk.
But correct me if I am wrong.
I would like to ask to include the RTTI patch for i386 in trunk.
With i386 interface
problems have to be solved yet.
I hope that the included file gives you some clues.
Thanks, Alfred.
TestInterfaceRTTI.lpr
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman
test on simple ARM (Pi[2], BBB).
If you provide me with code !
Thanks again, Alfred.
-- Origineel bericht --
Van: "Steve Hildebrandt"
Aan: fpc-devel@lists.freepascal.org
Verzonden: 25-2-2015 19:16:17
Onderwerp: Re: [fpc-devel] RTTI interface & variant late binding issue
(
patch will be included soon in trunk.
One (first) request:
Would it be ok to add pfConstRef to the TParamFlag in typinfo.pp ?
One (second) request:
The same RTTI on ARM would also be very welcome.
As stated before, my interest is running mORMot on ARM (e.g. Raspberry
Pi[2]).
Many thanks, Alfred
Hello to all,
While enjoying variant late binding for a couple of month now, I would
like to ask for an update on the status of RTTI.
The mORMot developer has designed a work-around for the missing RTTI.
This works well.
But it would be (much) nicer to be able to use RTTI without workaround.
69 matches
Mail list logo
