Hi,
On Fri, 5 Aug 2011, Marcus Sackrow wrote:
> perhaps I didnt choose the name for the define well
> in fact I'm a little bit in trouble here because normaly at amiga
> /xxx/ would be in something like ../xxx/ (in Linux) and so its implemented in
> FExpand atm,
> but the make util (and much oth
Hi,
On Fri, 5 Aug 2011, Karoly Balogh wrote:
> The problem with your example in particular that /System/Development as
> Amiga path is perfectly valid, as it means ../System/Development in POSIX
> path, not System:Development/ Having this in FExpand() affects all apps
> using the
Hi,
Yes, it's caused by a recent change I made. I have a half-ready patch,
should be fixed over the weekend. However, if you use -O2 only to build
the compiler itself instead, it shouldn't appear.
Charlie
On Sat, 18 Jan 2014, Martin wrote:
> Just svn updated (after make clean) trunk to revisio
Hi,
On Mon, 24 Feb 2014, Sven Barth wrote:
> Am 24.02.2014 17:29, schrieb Michael Schnell:
> > On 02/24/2014 03:41 PM, Sven Barth wrote:
> > > are normally OS independant as they normally use corresponding CPU
> > > instructions.
> > Of course for simple stuff like inc/dec I can (better) use ato
Hi,
On Sat, 22 Feb 2014, Sven Barth wrote:
> With revision 26849 which I just committed a few minutes ago an imporant
> milestone was reached for reviving the M68k port: the cross compiled compiler
> is now not only able to compile a program, but this program is also able to
> run correctly!
>
>
Hi,
On Mon, 10 Mar 2014, Sven Barth wrote:
> > Well, today on IRC you mentioned Atari too many times for an Amiga guy's
> > taste, so I couldn't resist...
>
> Once is already too many? :P
Yes! :)
> > http://charlie.amigaspirit.hu/screenshots/uae/UAE-FPC-m68k-2.7.1-FirstEver.png
> >
> > :)
>
> C
Hi,
We were profiling our code, and one RTL function regularly popped up in
close to the top in the profiling list.
It's remove_freed_fixed_chunks(). Can someone explain to me under what
condition this code is triggered very often and/or could take long to
execute (there's a loop in there)?
Mayb
Hi,
I think there are several issues with the cmem memory allocator. The main
issue that it "breaks" the underlying malloc() memory alignment, by adding
a four/eight byte size value to the start of each block for the sole
reason to be able to throw Runtime Error 204 in case someone tries to free
a
Hi,
On Wed, 19 Nov 2014, Mark Morgan Lloyd wrote:
> > At least on Linux, malloc() is documented to align to 64 bit on 32 bit and
> > 128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that
> > to 4 bytes and 8 bytes, respectively.
>
> Since cmem is intended for use by FPC, I don'
Hi,
On Wed, 19 Nov 2014, Jonas Maebe wrote:
> > Since the RTL's allocator is documented to align to 16 bytes
>
> Where?
Ok, that's actually a very good question. :) I didn't find it anywhere,
except some earlier ML/forum posts revealed by Google.
However, in practice it still seems to align to
Hi,
On Wed, 19 Nov 2014, Marco van de Voort wrote:
> > Since the RTL's allocator is documented to align to 16 bytes, it's
> > definitely an issue also with Pascal code. We do have code where also
> > Pascal side triggers the aligment issue, but indeed, the main issue is
> > with linked C libs, de
Hi,
On Tue, 23 Dec 2014, Maciej Izak wrote:
> I've Decided to close the "FreeSparta". Thanks you all for your interest.
> There are several
> reasons.
> [...]
> When I look for new jobs, it seems that there are no more jobs for
> Pascal/Delphi Programmers. Now
> in my new job I'm using Java EE
Hi,
On Sun, 15 Nov 2015, Michael Van Canneyt wrote:
> Strange, I created a test before committing, and it ran fine. Well. I
> reinstated line 1132. But according to logic, that line should not be
> necessary. Maybe I am not properly seeing a case where it can go wrong.
Wild try/guess just by loo
Hi,
On Sun, 5 Jun 2016, Sandro Cumerlato wrote:
> fpc svn trunk version 33910 building fails with error:
> *..snip..*
>Compiling .\fcl-db\src\export\fpxmlxsdexport.pp
>Compiling .\fcl-db\src\sqldb\interbase\fbadmin.pp
> The installer encountered the following error:
> Compilation
Hi,
On Sun, 21 Aug 2016, Michael Ring wrote:
> So unless there is a way to find out which registers get used by a procedure
> the only thing I can do to make interrupt routines as lean as possible is to
> not use procedures in them if possible.
There is a way, of course. Seems like the MIPS CG w
Hi,
On Sun, 21 Aug 2016, Sergei Gorelkin wrote:
> It is actually the opposite way around.
> g_save_registers/g_restore_registers methods are only used for first
> implemented targets (i386 and maybe m68k). All newer targets are written
> without calling them, since they are completely inappropria
Hi,
On Wed, 23 Nov 2016, Alfred wrote:
> 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% cor
Hi,
On Wed, 23 Nov 2016, Alfred wrote:
> > TL;DR: if this patch was accepted into NewPascal w/o comments or concerns,
> > then "ouch"...
>
> Thanks for your advice.
> This is exactly why NewPascal is here !
>
> Have an idea. Implement. Make public.
> perfect:=false;
> while (NOT perfect) Use; Get
Hi,
On Wed, 14 Dec 2016, Michael Schnell wrote:
> Of course another (better) option would be a fpc directly creating
> WebAssembly, but I understand that this will take a lot of time.
There is some interest in a WebAssembly backend, but yes it will take a
lot of time. No spoilers for now, and no
Hi,
On Thu, 16 Mar 2017, LacaK wrote:
> Then I get another error:
>test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
> .\Intel_IPP\ippcoremt.lib
>
> Am I doing something wrong, or there is some kind of incompatibility
> between format of supplied libraries and object files supported
Hi,
On Sun, 28 May 2017, John Paul Adrian Glaubitz wrote:
> When trying to cross-build fpc for sparc64, I ran into linker issues. I was
> able to resolve these when changing the ELF format from 32 to 64 bits in
> compiler/system/t_linux.pas and changing the dynamic loader path from
> /lib/ld-linu
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> Running the file utility on one of the object files shows that the
> assembler did not generate 32-bit code. So, at least a hotfix here
> would be to pass "-m32" to the assembler.
That is easy to add, see in compiler/sparc/cpugas.pas, M
Hi,
The list server rebooted this morning. We're investigating with the
hosting service why. If you got mails multiple times or your mail got
lost, this is why. By now, everything should be back to normal. Sorry
about the inconvenience.
Charlie
___
fpc-
Hi,
On Mon, 29 May 2017, Mark Morgan Lloyd wrote:
> My recollection is that the SPARC64 code generator is immature,
> hopefully Jonas will comment on that.
Not sure what "immature" means, granted, I don't know anything about
SPARC, but from what I see, FPC definitely handles SPARC as a 32bit onl
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:14:26PM +0200, John Paul Adrian Glaubitz wrote:
> > On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote:
> > > I tried adding "-32" like this:
> >
> > Even passing "-Av8plus" does not help
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:25:34PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > > > Even passing "-Av8plus" does not help. So, the options from
> > > > compiler/sparc/cpugas.pas are definitely not
Hi,
On Mon, 29 May 2017, Tomas Hajny wrote:
> > It is, but it's *pregenerated*, and committed to the SVN. The build
> > process doesn't generate any Makefiles, actually. (Lets not argue now it
> > is a nice practice or not, it is what it is...) To fix this, one has to
> > regenerate them. But it'
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> On Mon, May 29, 2017 at 02:57:51PM +0200, Karoly Balogh (Charlie/SGR) wrote:
> > Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
> > added -32 into sparc/cpugas.pas file as I said, and from th
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> In the end, I want to build the Debian package. So, the patches have
> to apply against that version.
Well. I applied a 1 line patch against rtl/linux/Makefile.fpc, to append
-32 when it builds the startup code, regenerated the Makefile
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Which is because the buildbox doesn't have these 32bit libraries
> installed, so FPC obviously cannot link against them. This is because the
> very limited multiarch you mentioned before I guess. Now, FPC doesn't n
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > Which is because the buildbox doesn't have these 32bit libraries
> > installed, so FPC obviously cannot link against them. This is because the
> > very limited multiarch you mentioned before I guess. Now, FPC doesn't need
> > Libc on l
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> Make sure to pass -L/lib32 to the linker because that's where libc6-sparc
> gets installed into:
>
> root@deb4g:~# dpkg -L libc6-sparc |head
> /.
> /etc
> /etc/ld.so.conf.d
> /etc/ld.so.conf.d/zz_sparc-biarch-compat.conf
> /lib
> /lib32
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> However, these also seem to be installed in /usr/lib32... So build running
> now, lets see what happens.
Different error: ... :/ I would gladly keep working on this, but I kinda
ran out of time for now, I can take a deeper look
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> > However, these also seem to be installed in /usr/lib32... So build running
> > now, lets see what happens.
>
> Different error: ... :/ I would gladly keep working on this, but I kinda
> ran out of time for now
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for
> SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe
> it's also possible to just add ASTARGET=-32 into the make command l
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > Can you try if you can reproduce this?
>
> Sure. Can you put the cross-compiled ppcsparc somewhere so I can find
> and use it?
You don't need one. :) See my other mail. Although I did crosscompile a
new bootstrap compiler, in the end
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> Like this:
>
> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
>
> This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
> Debian SPARC64 box without patching anything.
J
Hi,
On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote:
> > However, it should probably not be merged to fixes, because it may be a
> > breaking change for older Sparc/Linux versions (see my previous e-mail;
> > note that the situation with MIPS was probably different, because the
> > support o
Hi,
On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote:
> make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
So Adrian, I've got a question. Looking at fixing this in the right way,
the linker search paths at least.
What's the right directory to search
Hi,
On Tue, 30 May 2017, Marco van de Voort wrote:
> In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > Err, those are invoked directly from the Makefile, not invoked from inside
> > FPC. But you're right, that will be also a problem... Some platforms still
Hi,
We had numerous reports over the past few weeks, that the FPC/Lazarus
Bugtracker registration verification was broken. Thanks to the work of
Michael van Canneyt, it should be fixed now.
If you had trouble creating a bugtracker account in the last few weeks,
please try again now.
Charlie
Hi,
On Mon, 31 Jul 2017, Werner Pamler wrote:
> If the URL exists everything is fine (note on Windows, that the OpenSSL
> dlls must be copied to the exe directory for the demo to work). If the
> URL does not exist, but the server responds, the program returns the
> well-known error 404 (if the 40
Hi,
On Mon, 7 Aug 2017, Curtis Hamilton wrote:
> I'm interested to know if there has been work on fpc for
> FreeBSD/PowerPC. I'm interested in the status and helping maintain fpc
> for this platform.
FreeBSD for PowerPC never existed in FPC (it's not even in the internal
platform list, only Free
Hi,
On Tue, 8 Aug 2017, Karoly Balogh (Charlie/SGR) wrote:
> > I'm interested to know if there has been work on fpc for
> > FreeBSD/PowerPC. I'm interested in the status and helping maintain fpc
> > for this platform.
>
> FreeBSD for PowerPC never existed in
Hi Marco,
On Tue, 8 Aug 2017, Marco van de Voort wrote:
> > FreeBSD for PowerPC never existed in FPC (it's not even in the internal
> > platform list, only FreeBSD/i386 and FreeBSD/x86-64).
>
> I started on it, but stopped due to lack of time.
Mind if I fiddle with these things? I don't intend t
Hi,
On Wed, 9 Aug 2017, Curtis Hamilton wrote:
> I just formally subscribed to this mailing list.
>
> I'm interested in fpc on FreeBSD/PowerPC, however, I don't want to
> create any additional work nor break something that's not broken. That
> being said, I'm willing to work on this alone or with
Hi,
On Thu, 10 Aug 2017, Marco van de Voort wrote:
> > The questions is, can I just go in and upgrade our syscall interface to
> > the newer calls (where makes sense), or do we intend to support older
> > systems too?
>
> To my knowledge there is no universal "newer" and "older" BSD syscall
> set
Hi,
On Sat, 2 Sep 2017, Marco van de Voort wrote:
> The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it
> defines an array with texpropcode as range.
>
> This prohibits building of trunk.
Sven fixed it already in r37109.
(The quick-response advantage of receiving build no
Hi,
On Wed, 20 Sep 2017, Christo wrote:
> I have made an attempt at fixing an AVR related bug. Since this is my
> first attempt at messing with the compiler, I would like a review and
> critique of my attempt.
> (...)
>
> Can anyone see any problems with this approach, or perhaps suggest a
> bet
Hi,
On Thu, 30 Nov 2017, Marco van de Voort wrote:
> For Downloads, please use the FTP server at
>
> ftp://freepascal.stack.nl/pub/fpc/dist/3.0.4/
Not sure why Marco decided to redirect everything to the stack.nl mirror
as primary source in his announcement, but everything should be on
ftpmaster
HI,
On Tue, 26 Dec 2017, Thorsten Engler wrote:
> > Item: BYTE BASED ItemPtr;
>
> Ignoring any other considerations for now, I would have at least used a
> logical extension derived from already supported syntax:
>
> Item: Byte absolute ItemPtr^;
As far as I understand (I did not try) this was
Hi,
On Mon, 19 Feb 2018, Sven Barth via fpc-devel wrote:
> It's not the same scenario as heaptrc is entirely working in the RTL
> without any compiler extension (aside from the -gh parameter). Profiling
> code however would require extensions to the compiler whereby it would
> also need to handle
Hi,
Just some technical background to this discussion, I don't care who
documented what, I'm just stating how it works. :P
On Thu, 5 Apr 2018, Ondrej Pokorny wrote:
> >>> Now, it is also correct that the compiler developers are aware that
> >>> many people rely on this implementation detail.
> >
Hi,
On Wed, 13 Jun 2018, Adriaan van Os wrote:
> >> Yuriy Sydorov wrote:
> >>> No special version is needed, use 3.0.4 release sources or trunk
> >>> sources.
>
> I have fpc-3.0.4 installed on OS X 10.6.8. In a separate 3.0.4 sources folder,
> I issue
>
> make clean crossall crossinstall OS
Hi,
On Mon, 30 Jul 2018, J. Gareth Moreton wrote:
> I would say that that's a little naïve and dangerous to think like that.
> Sure, Windows might have the means to clean up memory after an
> application terminates, but not all platforms have such heap
> deallocation features (e.g. pure DOS, wher
Hi,
On Thu, 25 Oct 2018, Michael Van Canneyt wrote:
> >>> - Make Exception handling, TLS etc use the infrastructure that
> >>> libpthread is providing
> >>
> >> TLS is handled already by libpthread. I doubt you will gain much there.
> >>
> >
> > GCC has (depending on the platform) a faster imple
Hi,
On Thu, 25 Oct 2018, Florian Klaempfl wrote:
> >> That is good news. The contours of a TODO list are becoming visible :)
> >>
> >> But we may need also need a solution for other platforms, which means the
> >> current system should remain in place for those platforms where such a
> >> system
Hi,
On Mon, 31 Dec 2018, Olivier Coursière via fpc-devel wrote:
> > if you want, I can integrate those changes into trunk for you.
> Thank you for the offer but i should have some free time in the next two
> days. I should already have the change in a 3.0.4 branch. It should be
> easy to port to
Hi,
(Not sure if Olivier is on the list, so keep cc:-ing him...)
On Mon, 31 Dec 2018, Karoly Balogh (Charlie/SGR) wrote:
> > Not really. I have investigated what need to be done for x86-64 port but
> > the assembly part (cprt0.as) was enough to dissuade me so far ;-) Other
> >
Hi,
On Tue, 1 Jan 2019, Karoly Balogh (Charlie/SGR) wrote:
> (Not sure if Olivier is on the list, so keep cc:-ing him...)
>
> So, bottom line, see the following patch:
>
> http://charlie.amigaspirit.hu/temp/private/haiku_pascal_sysinit.patch
I have updated the patch. The ex
Hi,
On Wed, 2 Jan 2019, Olivier Coursière wrote:
>> Should linking without libc (as in, libroot) be supported?
> I have only maintained the libc/libroot part since the beginning of
> Haiku port ten years ago.
Well, we do have other libc-only ports, like the macOS/Darwin version.
It's best to re
Hi,
On Wed, 2 Jan 2019, Karoly Balogh (Charlie/SGR) wrote:
> > - port/fix to 64bit
> >
> > With the already proposed changes to simplify the initialization part,
> > it is probably "just" a matter of :
> > (...)
>
> Yup, that list sums it up. Also I&
Hi,
On Fri, 4 Jan 2019, Olivier Coursière via fpc-devel wrote:
> > There seems to be something wrong with the signal setup so strace is
> > used to hide a fatal error... Also file handling doesn't really work
> > now. But even to get to this level in a few hours was nice.
> For signal handling, m
Hi Olivier,
On Fri, 11 Jan 2019, Olivier Coursière via fpc-devel wrote:
> > It would be nice to also get regular testsuite results for Haiku OS!
> I have tested VM automation with vagrant and i should be able to
> automate something to launch and upload the result in one click. And
> maybe for
Hi
On Fri, 11 Jan 2019, Pierre Muller wrote:
> > Make cycle works fine as of current trunk, however "make all" causes a
> > KDL, unless you disable fcl-process usage in fpmake. See this patch:
>
> I already managed to generate a snapshot:
>
> ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/x86_64
Hi,
On Thu, 28 Mar 2019, J. Gareth Moreton wrote:
> I think the official unsigned 32-bit integer type in Pascal is
> "LongWord". As others have said, be aware that pointers are 64-bit under
> x64... that's kind of why it's called x64! If you absolutely must have
> a packed record with 32-bit typ
Hi,
On Mon, 27 May 2019, Pierre Muller wrote:
> The merge of the two commits generate 3 conflicts, but those are easily
> solved.
> See attached patch.
>
> Olivier, did you test the fixes_3_2 branch?
> Do you think it is reasonable to enable x86_64-haiku target in that branch?
I think if al
Hi,
On Sat, 15 Jun 2019, J. Gareth Moreton wrote:
> Ryan Joseph requested that I reply to this to show that it's in the
> mailing list. Hopefully the technical problems can be resolved!
There was an issue affecting GMail users, and GMail's SMTP servers over
IPv6. This has been resolved by now.
Hi,
On Fri, 29 Nov 2019, Werner Pamler wrote:
> Who takes care of the wiki software? There is another issue that it is
> not possible any more to replace existing uploaded images by new
> versions (at least when I tried the last time, some weeks ago).
It's me. And I know. I spent today 3 hours a
Hi,
On Mon, 27 Apr 2020, Sven Barth via fpc-devel wrote:
>> Well, I'm surprised and impressed you got it to work at all...
>> Quite an achievement.
>
> Considering that we already support AVR as well I was rather confident
> here. :D Maybe in the future we can also add GameBoy support which uses
Hi,
On Sat, 20 Jun 2020, Yuriy Sydorov wrote:
> I've added the generic cs_opt_unused_para optimization option.
> In future, if needed, more fine-grained related options can be introduced.
>
> So now the parentfp optimization is enabled for -O2 and higher.
Yuriy, your changes seem to have broken
Hi,
I've just fixed the EMX main branch daily snapshot compilation
procedure. I'm writing this from the machine which compiles the
snapshots. /fcl/os2/classes.pp needs a little patch, to compile
well, attached. The current snapshot which i've uploaded to
ftp.freepascal.org already contains my patc
Forgot to attach, sorry... :) Here it comes.
28c28,29
< sysutils;
---
> sysutils,
> typinfo;
32d32
<
35,37d34
< uses
< typinfo;
<
40d36
<
Hi,
I'm just sitting here at the machine which compiles the OS/2
snapshots. I hope someone who can answer my question is still
awake. :)
FPC/2 fails to cycle currently, because some new errors just
appeared in pmstddlg.pas file in the RTL. It seems to be,
that the new compiler is more strict on th
Hi,
On Mon, 11 Jan 2021, Sven Barth via fpc-devel wrote:
> So the idea is to add support for ROL/ROR with Carry support as the
> current Rol*/Ror* functions don't support that. Florian then said that
> he's open to suggestions under some restrictions. Considering that the
> current Rol*/Ror* intr
Hi
On Mon, 19 Apr 2021, Curtis Hamilton via fpc-devel wrote:
>> Thanks for reaching back. I’d the feeling that there wasn’t much
>> interest when I didn’t get a lot of feedback from the FreeBSD/PowerPC
>> community.
>>
>> I’ve looked at the changes to support aarch64. I’ve already gotten
>
Hi
On Sun, 8 Aug 2021, Florian Klämpfl via fpc-devel wrote:
> > One of the guys responsible for glibc in Fedora gave this explanation:
> >
> >> It's related to startup code hardening in glibc. In general, it's
> >> not forward-compatible to call internal glibc functions this way.
> >> __libc_csu
Hi,
On Sun, 12 Dec 2021, Yuriy Sydorov via fpc-devel wrote:
> > set CPUOPTS=-O2 -Opcoreavx -Cpcoreavx
> > set CPUOPTS64=-Cfavx
> >
> > I didn't enter those in Lazarus I think, so that should be pretty much
> default.
>
> Should be fixed now. The AVs have occurred only when targeting the AVX FPU.
Hi,
On Mon, 13 Dec 2021, Yuriy Sydorov via fpc-devel wrote:
> > I've no doubt the problem is in the m68k target, and the IE only exposed
> > it, but regardless, register allocation is not one of my strenght, so
> > ideas welcomed.
>
> The new internal error catches incorrect usage of get_alias().
Hi,
On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> Yes, a.out support (which is used on Atari) has been dropped in 2.31.
> But i've added it back in, and cross-binutils of 2.34 can be found at
> http://tho-otto.de/crossmint.php#binutils
Won't really help. As you found out already, sec
Hi,
On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> Yes, but i never used that "brown" tool. For one, i don't like its
> confusing naming convention (depending on gcc version, it is "brown",
> "extrabrown", "superbrown" etc). But more importantly, it needs an extra
> tool to be run afte
Hi,
On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote:
> > And of course i have to find out what causes vlink to put that strange
> > program flags in the header.
>
> I think i found the reason for that. The offending lines in vlink/main.c are:
> (...)
> (at this point the option argument ha
Hi,
On Fri, 28 Jan 2022, Thorsten Otto via fpc-devel wrote:
> On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:
>
> > i still want to try to figure out what's wrong when using gas/ld)
> I get the the feeling that there must be something else going wrong:
>
> - when i ru
Hi,
On Sat, 29 Jan 2022, Thorsten Otto via fpc-devel wrote:
> On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote:
>
>> a fixed GAS/LD support would be nice, of course.
>
> Yes, but currently i'm a bit lost here. Since that combination currently
> does not
Hi,
On Sat, 29 Jan 2022, Karoly Balogh via fpc-devel wrote:
> > There are other parts that should be improved, and seem more important
> > to me (like ARGV support, completing the GEMDOS/BIOS/XBIOS interface
> > etc)
>
> Totally agree here.
Just one more note here, for t
Hi,
On Sat, 29 Jan 2022, Thorsten Otto via fpc-devel wrote:
>> Again, this isn't a generic problem, but Atari specific.
>
> Yes, but theoretically, win32 should have the same problem. As far as
> i've seen, ReadFile() is used there. but fpc_readln_end() tries to read
> until it encounters a LF, a
Hi,
On Tue, 1 Feb 2022, Thorsten Otto via fpc-devel wrote:
> On Dienstag, 1. Februar 2022 09:11:21 CET Pierre Muller via fpc-devel wrote:
>
> > thus you should use
> > -Aas-out
> > compiler option.
>
> Ah thx. Would make more sense to just use "as" like for other targets,
> but i see that this ta
Hi,
On Sun, 6 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > - Running the same binaries in SingleTOS, they both give me "Internal
> > error 2004121202'. Then they both crash with a bus-error, too.
>
> That internal error is currently striking back. This happens both with
> my own compiled bina
Hi,
On Mon, 7 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > On Montag, 7. Februar 2022 10:31:01 CET Thorsten Otto via fpc-devel wrote:
>
> > Nice, that's it. Compiling everything for 68020, and it works.
>
> Hm, or maybe not. A few hours later, installing a freshly compiled
> version, i get th
Hi,
On Mon, 7 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > It's just that you need to provide it with the correctly compiled units
>
> Yes, i see. But that requires some manual fiddling with the library
> directories, and you need both 68000 and 68020 versions somehow.
>
> How do the Amiga fo
Hi,
On Mon, 7 Feb 2022, Karoly Balogh via fpc-devel wrote:
> Not under mind, but going with this would probably mean
> giving up TOS support.
*Not under MINT, I mean, sorry for the typo.
Charlie
___
fpc-devel maillist - fpc
Hi,
On Mon, 7 Feb 2022, Thorsten Otto via fpc-devel wrote:
> > but going with this would probably mean giving up TOS support.
>
> Yes, that 8.3 restriction might be the worst that was ever made. But
> even unices of that time allowed only 14 character long filenames.
It is also the main reason w
Hi,
On Thu, 10 Feb 2022, Sven Barth via fpc-devel wrote:
> Thorsten Otto via fpc-devel schrieb am
> Do., 10. Feb. 2022, 15:47:
>
>>> Cause in the variant you mentioned where would the allocated memory be
>>> stored?
>> I'm not that familiar with ObjectGEM yet, but i think the
>> allocated pointe
Hi,
On Sat, 12 Feb 2022, Thorsten Otto via fpc-devel wrote:
> I'm currently trying to set this up and have a problem with the
> cross-compiler. Although that was configured for atari and 68000, it
> still has LINUX and CPU68020 defined while processing the config file.
That probably can't be hel
Hi,
On Sat, 12 Feb 2022, Florian Klämpfl via fpc-devel wrote:
> >> My config file has -Tatari set, so the LINUX define is no issue. But if
> >> i invoke the compiler without excplicit -Cp, it will generate code
> >> for 68000, but take the libraries from the 68020 directory. It works as
> >> inte
Hi,
This e-mail was sent as a test of our ML infrastructure after a server
upgrade. Please ignore.
Charlie
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi,
On Tue, 12 Apr 2022, J. Gareth Moreton via fpc-devel wrote:
> To complement aligned records, I'm trying out an implementation of
> aligned records. Like how you might declare an aligned record as follows:
>
> type AlignedVector = packed record
> X, Y: Double;
> end align 16;
Is this "a
Hi,
On Fri, 19 Aug 2022, Michael Van Canneyt via fpc-devel wrote:
> > With actual FPC main (61debb15) got the below error. No error with an
> > earlier FPC main (8028a769). Any idea?
>
> It's a pretty basic unit, I can't imagine that it would not have been
> compiled.
I think such errors are als
Hi,
On Thu, 10 Nov 2022, Sven Barth via fpc-devel wrote:
> You still need to feed the model with the necessary rules and with
> necessary training data of both correct and incorrect approaches.
>
> But even then *I* wouldn't want to have any of that black box mambo
> jumbo in FPC, cause when a bu
Hello,
This is a test e-mail following some listsserver maintenance, please
ignore.
Charlie
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
1 - 100 of 103 matches
Mail list logo
