alpine and musl people are working together quite well. no complaints there.
Quentin Rameau wrote:
>> Apart from patching programmes to work with musl, Alpine has around
>> sixty patches for musl itself[0].
>> These are upstream patches until the next release is tagged.
Oh, thanks, they are, just looked.
--
caóc
> Apart from patching programmes to work with musl, Alpine has around
> sixty patches for musl itself[0].
These are upstream patches until the next release is tagged.
>>> I did check alpine package web browsers: it's full of libgcc_s deps.
>>> You can forget alpine as a no libgcc_s distro. At least, they do maintain
>>> the
>>> patches required in order to compile many software packages with the musl
>>> libc.
>> Patching the shit out of everything...
>> I don'
Patching software to work with musl libc (and sending patches
upstream) improves overall software.
Not that much is needed. Most programs work out of the box with musl.
There was a talk about this a few months ago.
https://video.fosdem.org/2017/K.4.601/building_a_distro_with_musl_libc.vp8.webm
On Tue, Jul 04, 2017 at 01:13:21AM +, sylvain.bertr...@gmail.com wrote:
> I did check alpine package web browsers: it's full of libgcc_s deps.
>
> You can forget alpine as a no libgcc_s distro. At least, they do maintain the
> patches required in order to compile many software packages with th
I did check alpine package web browsers: it's full of libgcc_s deps.
You can forget alpine as a no libgcc_s distro. At least, they do maintain the
patches required in order to compile many software packages with the musl
libc.
Regards,
--
Sylvain
Sylvain Bertrand wrote:
> For c++ retards and sub-humans
Delete your account.
On Mon, Jul 03, 2017 at 05:33:14PM +0200, hiro wrote:
> I should, so there isn't any? I have alpine here ready and waiting...
Indeed, alpine is musl based (thx to the authors for all the patching, hope
upstream they were not *ss h*les and committed the patches).
For sane C code (or at least have
I should, so there isn't any? I have alpine here ready and waiting...
On 7/3/17, sylvain.bertr...@gmail.com wrote:
> On Mon, Jul 03, 2017 at 02:53:30PM +0200, hiro wrote:
>> so if i'm on musl and tell gcc to link statically it should just work?
>> in that case i'll try and report.
>
> Meaning tha
On Mon, Jul 03, 2017 at 02:53:30PM +0200, hiro wrote:
> so if i'm on musl and tell gcc to link statically it should just work?
> in that case i'll try and report.
Meaning that, in theory, you can have a libc which does not require libgcc_s
(coze of pthread_cancel) with musl.
Namely, you should be
so if i'm on musl and tell gcc to link statically it should just work?
in that case i'll try and report.
On 7/3/17, sylvain.bertr...@gmail.com wrote:
> On Mon, Jul 03, 2017 at 01:45:39PM +0200, hiro wrote:
>> I have a related question. how can i statically link X11 programs
>> nowadays? Without d
On Mon, Jul 03, 2017 at 01:45:39PM +0200, hiro wrote:
> I have a related question. how can i statically link X11 programs
> nowadays? Without dlopen obviously...
AFAIK, you can statically link all of them... but it was a long time ago.
The real culprit for static linking is in the gnu glibc: pthr
I have a related question. how can i statically link X11 programs
nowadays? Without dlopen obviously...
On Sun, Jul 02, 2017 at 08:43:59AM -0300, Alba Pompeo wrote:
> There's tinyxserver and the accompanying tinyxlib but they are kind of
> abandoned.
> I never tried it myself but if you do I'd be interested to know how it goes.
> https://github.com/idunham/tinyxserver
> https://github.com/idunham/tin
For XOrg compilation instructions/process, I'd look at CRUX's ports
[0][1]. It's at least a couple dozen ports to read through but at
least they're simple port/shell scripts.
As for Nano-X (nee, microwindows), it's an X11-like API (though not
compatible) derived from mini-X. microwindows adds a
There's tinyxserver and the accompanying tinyxlib but they are kind of
abandoned.
I never tried it myself but if you do I'd be interested to know how it goes.
https://github.com/idunham/tinyxserver
https://github.com/idunham/tinyxlib
There's also Nano-X and the accompanying nxlib but I don't know
On Sun, Jul 02, 2017 at 09:06:22AM +0200, Laslo Hunhold wrote:
>
> Wayland in itself actually is a very nice protocol. However, you cannot
> do much with it alone, as the compositor and everything on top (input
> handling, clipboard, keyboard-layouts, ...) have to be done by hand.
>
Can you elabo
On Sun, Jul 02, 2017 at 09:06:22AM +0200, Laslo Hunhold wrote:
> The way they did Wayland was kind of nice, but even it lacks
> some modern ideas which should've been implemented now that the entire
> windowing system is revamped anyway, and here I'm talking about
> color management, accessibility
On Sat, 1 Jul 2017 19:51:59 -0400
Rendov Norra wrote:
Hey Rendov,
> Are there any XOrg implementations that aren't a pain to compile?
like most legacy codebases, you end up with a difficult to compile
chunk. Others might give you more insight in what to choose.
> I've heard people complain abo
Are there any XOrg implementations that aren't a pain to compile? I've
heard people complain about wayland but I haven't heard any good
reason as to why it's actually bad, so I'm considering just going with
that if it's less of a pain.
21 matches
Mail list logo
