On Monday 13 February 2006 17:55, Lord Satan wrote:
> > Is anybody using a way around or are you all day waiting?
>
> The way around is running under Linux where linking is much faster.
> As often said the speed problems are caused by the GNU linker and AFAIK
> there is no way to solve this other t
PROTECTED]
Sent: Monday, February 13, 2006 9:38 PM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Who Discussed Linker Slowness?
On 2/13/06, anthony boudouvas <[EMAIL PROTECTED]> wrote:
> Yes but this way, we have every time we build something faster
> link-time, which is esse
Felipe Monteiro de Carvalho wrote:
Perhaps the ideal would be if we could have one LCL without
smartlinking for the creation process and another with smartlink for
the final Release? How big / difficult would this be?
Yes, this would really be good. Especially if the one could freely
choose
On 2/13/06, anthony boudouvas <[EMAIL PROTECTED]> wrote:
> Yes but this way, we have every time we build something faster link-time,
> which is essential because
> we do it continuously, and when we are done we use strip (and then upx) and
> we get
> smaller executables easily...
I think you did n
PROTECTED]
Sent: Monday, February 13, 2006 7:30 PM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Who Discussed Linker Slowness?
On 2/13/06, anthonyb <[EMAIL PROTECTED]> wrote:
> I rebuild Lazarus from the menu and linker seems to be ok now... Is it
> the correct way to do so ??
By do
On 2/13/06, anthonyb <[EMAIL PROTECTED]> wrote:
> I rebuild Lazarus from the menu and linker seems to be ok now...
> Is it the correct way to do so ??
By doing this you will lose the benefits of smartlinking, i.e.
executables about 30% smaller.
This is a exchange. With smartlinking the executable
anthonyb wrote:
I rebuild Lazarus from the menu and linker seems to be ok now...
Is it the correct way to do so ??
Actually rebuilding just the LCL is good enough.
Vincent
_
To unsubscribe: mail [EMAIL PROTECTED] with
I rebuild Lazarus from the menu and linker seems to be ok now...
Is it the correct way to do so ??
-Original Message-
From: Johannes Nohl [mailto:[EMAIL PROTECTED]
Sent: Monday, February 13, 2006 5:43 PM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Who Discussed Linker Slowness
> Is anybody using a way around or are you all day waiting?
The way around is running under Linux where linking is much faster.
As often said the speed problems are caused by the GNU linker and AFAIK there
is no way to solve this other than writing a new linker.
__
And there's really no way to accelerate linking - in any way?
Maybe (for testing purposes only) just create a library per unit and
form and run it from a earlier compiled and already linked
application?
It is boring to compare to delphi, allways. But there must be
different ways to target. If it is
Christian U. wrote:
you could add a "Final Build" Menu item.
I think, this is an good idea, a publish menue Item can strip and maybe upx
the executable.
An public folder describes where to place the final executable.
And that is exactly what publish project can do, when you have
configured
> you could add a "Final Build" Menu item.
I think, this is an good idea, a publish menue Item can strip and maybe upx
the executable.
An public folder describes where to place the final executable.
Christian
_
To unsubscribe:
On 2/12/06, Johannes Nohl <[EMAIL PROTECTED]> wrote:
> Isn't it possible to run a compiled application without linking it
> together before?
Linking is the process of putting the compiler pieces together unit a
executable file.
So no, you cannot run unless you link.
--
Felipe Monteiro de Carvalh
Isn't it possible to run a compiled application without linking it
together before?
For testing a lazarus application it would be enough. If it's possible
you could add a "Final Build" Menu item.
Or am I completly out of logic? (I'm not very familliar with "internal stuff")
__
On Sun, 15 Jan 2006 20:21:04 +0100, Peter Vreman <[EMAIL PROTECTED]>
wrote:
>So in short: The only way to get a major speedup in linking is to have an
>internal linker so the .o is not needed anymore and can be stored in the
Has anyone compared various alternatives for ld (if there are
> You can expiriment yourself, use the 2.1.1 compiler from today and compile
> everything with option "-WI-".
Oh! Send -WI- to the compiler? or the linker with -k ?
Lars
_
To unsubscribe: mail [EMAIL PROTECTED] with
At 22:29 15-1-2006, you wrote:
> All those external references to DLLs are generated by the linker and don't
> need to be stored in the dcu. For FPC we can do the same since ld now also
> supports direct linking to DLL files. When the FPC port to win32 started
> that was not the case.
>
I remem
> All those external references to DLLs are generated by the linker and don't
> need to be stored in the dcu. For FPC we can do the same since ld now also
> supports direct linking to DLL files. When the FPC port to win32 started
> that was not the case.
>
I remember that was discussed in the art
At 20:40 15-1-2006, you wrote:
> So in short: The only way to get a major speedup in linking is to have an
> internal linker so the .o is not needed anymore and can be stored in the
> ppu. But i don't have the time to code such an internal linker so don't
> expect anything before 2007.
>
>
And
> So in short: The only way to get a major speedup in linking is to have an
> internal linker so the .o is not needed anymore and can be stored in the
> ppu. But i don't have the time to code such an internal linker so don't
> expect anything before 2007.
>
>
And I wonder about the Windows.a and
At 20:16 15-1-2006, you wrote:
>
>
> On Sun, 15 Jan 2006, L505 wrote:
>
> > What do PPU files contain? symbolic links or hard links?
>
> They don't contain links at all.
> The accompagnying .o files contain symbolic links, as they are standard
> elf or pecode object files.
>
> Michael.
>
Ahh
At 09:26 15-1-2006, you wrote:
What do PPU files contain? symbolic links or hard links?
See below:
"
- The .TPU format doesn't contain symbolic links to other units, it
contains hard
links to particular offsets in the interface part of other .TPU files. If
those other
units change their inte
>
>
> On Sun, 15 Jan 2006, L505 wrote:
>
> > What do PPU files contain? symbolic links or hard links?
>
> They don't contain links at all.
> The accompagnying .o files contain symbolic links, as they are standard
> elf or pecode object files.
>
> Michael.
>
Ahh I see.. does microsoft visual stu
On Sun, 15 Jan 2006, L505 wrote:
> What do PPU files contain? symbolic links or hard links?
They don't contain links at all.
The accompagnying .o files contain symbolic links, as they are standard
elf or pecode object files.
Michael.
__
What do PPU files contain? symbolic links or hard links?
See below:
"
- The .TPU format doesn't contain symbolic links to other units, it contains
hard
links to particular offsets in the interface part of other .TPU files. If those
other
units change their interface, the .TPU is made obsolete
Em Qui, 2006-01-12 às 15:14 -0700, L505 escreveu:
> If anyone finds some mailing lists or internet sites that show discussion if
> the
> gcc/gnu linker speed being improved (or why it is slow) please post in this
> thread.
> If no one has even made a note to the gcc tool chain team that the link
> Florian Klaempfl wrote:
>> Units imported from dlls require import entries. This would increse the
>> size of
>> executables significantly
>
> Yes, was afraid of that. We would need to make a wincommon or so, with
> all those that LCL uses (or any other measure of "common"), winextra,
> win2k, wi
Florian Klaempfl wrote:
Units imported from dlls require import entries. This would increse the size of
executables significantly
Yes, was afraid of that. We would need to make a wincommon or so, with
all those that LCL uses (or any other measure of "common"), winextra,
win2k, winxp, etc, Hmm
> Vincent Snijders wrote:
>> An extra handicap for the linker is the fact that the windows unit,
>> which is rather large is always smartlinked, resulting in (I estimate)
>> ten thouands of object files (archived in the .a file). You probably
>> won't have this amount of .o files in c programs.
>
>
Micha Nelissen wrote:
> Vincent Snijders wrote:
>
>> An extra handicap for the linker is the fact that the windows unit,
>> which is rather large is always smartlinked, resulting in (I estimate)
>> ten thouands of object files (archived in the .a file). You probably
>> won't have this amount of .
Vincent Snijders wrote:
An extra handicap for the linker is the fact that the windows unit,
which is rather large is always smartlinked, resulting in (I estimate)
ten thouands of object files (archived in the .a file). You probably
won't have this amount of .o files in c programs.
Can we sepe
> Of course it is probably the Win32 linker that is the real slow one, and I
> don't know
> why that is - so any mailing lists threads or sites you know of please
> post them here
> and/or discuss.
I guess part of the slowness is the use of GROUP() and the large
libpwindows.a
__
L505 wrote:
Of course it is probably the Win32 linker that is the real slow one, and I
don't know
why that is - so any mailing lists threads or sites you know of please post
them here
and/or discuss.
An extra handicap for the linker is the fact that the windows unit,
which is rather large is
> An extra handicap for the linker is the fact that the windows unit,
> which is rather large is always smartlinked, resulting in (I estimate)
> ten thouands of object files (archived in the .a file). You probably
> won't have this amount of .o files in c programs.
>
> Vincent.
>
Windows.ppu
34 matches
Mail list logo
