Re: [dev] Xorg implementations

2017-07-09 Thread hiro
alpine and musl people are working together quite well. no complaints there.

Re: [dev] Xorg implementations

2017-07-09 Thread Cág
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

Re: [dev] Xorg implementations

2017-07-09 Thread Quentin Rameau
> 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.

Re: [dev] Xorg implementations

2017-07-08 Thread Alba Pompeo
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

Re: [dev] Xorg implementations

2017-07-08 Thread robin
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

Re: [dev] Xorg implementations

2017-07-03 Thread sylvain . bertrand
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

Re: [dev] Xorg implementations

2017-07-03 Thread Bobby Powers
Sylvain Bertrand wrote: > For c++ retards and sub-humans Delete your account.

Re: [dev] Xorg implementations

2017-07-03 Thread sylvain . bertrand
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

Re: [dev] Xorg implementations

2017-07-03 Thread hiro
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

Re: [dev] Xorg implementations

2017-07-03 Thread sylvain . bertrand
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

Re: [dev] Xorg implementations

2017-07-03 Thread hiro
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

Re: [dev] Xorg implementations

2017-07-03 Thread sylvain . bertrand
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:

Re: [dev] Xorg implementations

2017-07-03 Thread hiro
I have a related question. how can i statically link X11 programs nowadays? Without dlopen obviously...

Re: [dev] Xorg implementations

2017-07-02 Thread Hiltjo Posthuma
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 >

Re: [dev] Xorg implementations

2017-07-02 Thread Louis Santillan
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

Re: [dev] Xorg implementations

2017-07-02 Thread Alba Pompeo
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

Re: [dev] Xorg implementations

2017-07-02 Thread Hiltjo Posthuma
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

Re: [dev] Xorg implementations

2017-07-02 Thread v4hn
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

Re: [dev] Xorg implementations

2017-07-02 Thread Laslo Hunhold
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

[dev] Xorg implementations

2017-07-02 Thread Rendov Norra
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.