Am 01.09.2016 00:15 schrieb "African Wild Dog" :
> And about GCC? It supports a wide variety of processors and OS.
Why would we want to depend on the behemoth that is GCC as a dependency
when FPC currently only needs an assembler and a linker and on some systems
not even that? That thought can als
On Wed, Aug 31, 2016 at 6:15 PM, African Wild Dog
wrote:
> Again,thanks for the detailed explanation. As this is a recurrent
> topic,maybe it would be a good ideia to create a wiki page with all these
> points.
>
http://wiki.freepascal.org/LLVM
thanks,
Dmitry
___
Hi,
On Wed, 31 Aug 2016, African Wild Dog wrote:
> > The code optimizers, yes. The rest, not so much.
> >
> >> Will the FPC team, somewhere in the future, adopt the LLVM as the
> >> backend on all platforms ?
> >
> > No, for various reasons:
>
> Again,thanks for the detailed explanation. As this
Hi,
On Wed, 31 Aug 2016, Anthony Walter wrote:
> I'm not too familiar with LLVM so I'll ask, is it at all likely that an
> LLVM compiler would produce significantly better/faster optimizations
> than FPC as it stand currently? What range would be talking about 100%
> faster? Less? More?
We just
Em quarta-feira, 31 de agosto de 2016, Jonas Maebe <
jonas.ma...@elis.ugent.be> escreveu:
> On 31/08/16 05:11, African Wild Dog wrote:
>>
> The code optimizers, yes. The rest, not so much.
>
>> Will the FPC team, somewhere in the future, adopt the LLVM as the
>> backend on all platforms ?
>
> No,
On 31/08/16 21:47, Anthony Walter wrote:
I'm not too familiar with LLVM so I'll ask, is it at all likely that an
LLVM compiler would produce significantly better/faster optimizations
than FPC as it stand currently? What range would be talking about 100%
faster? Less? More?
It depends on the kin
I'm not too familiar with LLVM so I'll ask, is it at all likely that an
LLVM compiler would produce significantly better/faster optimizations than
FPC as it stand currently? What range would be talking about 100% faster?
Less? More?
___
fpc-pascal maillis
> From the 'fpc -h' output.
> -XdDo not search default library path (sometimes required for
> cross-compiling when not using -XR)
Excellent, sure, it is the solution. ;-)
I do not have my pc here, will try tonight.
Write you later.
Fre;D
-
Many thanks ;-)
--
View this message in
On 2016-08-31 16:59, fredvs wrote:
> Or, maybe *-Xd * is the solution.
> ... What is -Xd ?
>From the 'fpc -h' output.
-XdDo not search default library path (sometimes required for
cross-compiling when not using -XR)
Regards,
Graeme
--
fpGUI Toolkit - a cross-platform GUI toolkit u
Hello Graeme.
> Take a look in your ~/.fpc.cfg file. If the following doesn't exist, add
> it, and specify the correct paths to the 32-bit libraries as found on your
> system.
Huh, of course it is the first thing that I did.
But, afaik, -Fl/something, has no impact on the search path of ld.
It
On 2016-08-31 16:25, fredvs wrote:
> Of course because /usr/lib/crti.o is 64 bit.
>
> The 32 bit libraries are in /usr/lib32/ and in /usr/local/lib32.
>
> How to tell to *ld* to search in /usr/lib32 + /usr/local/lib32 while
> linking?
Take a look in your ~/.fpc.cfg file. If the following doesn'
Hello.
How to define the search path of libraries while linking ?
In a FreeBSD 64 multiarch system, fpc32 compiles without problems but at
linking there is that message:
> /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for
> /usr/lib/crti.o
Of course because /usr/lib/crti.o i
12 matches
Mail list logo
