On Wed, Feb 11, 2015 at 07:37:00AM +0100, Julian Dammann wrote:
> > > Yes, I speak about static linking, because It is what we have in
> > > sbase, so dynamic linking is outside of this discussion (ant it is
> > > not suckless :P). And maybe compilers are smarters, but the link
> > > process is the
> > Yes, I speak about static linking, because It is what we have in
> > sbase, so dynamic linking is outside of this discussion (ant it is
> > not suckless :P). And maybe compilers are smarters, but the link
> > process is the same. Try it and you will see it. Even if you find
> > some too much sm
On Tue, 10 Feb 2015 21:45:29 +0100
k...@shike2.com wrote:
Hey k0ga,
> Yes, I speak about static linking, because It is what we have in
> sbase, so dynamic linking is outside of this discussion (ant it is
> not suckless :P). And maybe compilers are smarters, but the link
> process is the same. Try
> When you write a library one of the objects is to minimize
> what code is included in the binary when the library is linked.
> When you link with a library you extract object files from the
> archive, so all the functions of the object file are included
> in the program, even if the program don't
> On Tue, 10 Feb 2015 21:21:56 +0100
> k...@shike2.com wrote:
>
> Hey k0ga,
>
>> When you write a library one of the objects is to minimize
>> what code is included in the binary when the library is linked.
>> When you link with a library you extract object files from the
>> archive, so all the f
On Tue, 10 Feb 2015 21:21:56 +0100
k...@shike2.com wrote:
Hey k0ga,
> When you write a library one of the objects is to minimize
> what code is included in the binary when the library is linked.
> When you link with a library you extract object files from the
> archive, so all the functions of th
Good evening,
>
> What is left to discuss is where to put these functions. I would propose
> to place chartorunearr into rune.c, where already chartorune() and
> others reside.
> I would place readrune() and writerune() into a new file called
> runeio.c.
> The name doesn't really matter, becaus
Good evening fellow hackers,
working with sbase, we've decided a while ago to include libutf in the
repo and base all tools' UTF-8-support on it instead of the insane
wchar.h-interface.
Now that almost all tools have UTF-8-support, we, along the way,
implemented a number of utility functions which