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.
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
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
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
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
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:
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
>
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
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
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.
20 matches
Mail list logo