GLOB_BRACE

GLOB_BRACE

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

Hi,

I have hit the next stumbling block (show stopper):

src/shared/util.c: In function 'glob_exists':
src/shared/util.c:4376:36: error: 'GLOB_BRACE' undeclared (first use in
this function)
src/shared/util.c:4376:36: note: each undeclared identifier is reported
only once for each function it appears in


I see this is and non-standard posix extension. I guess that is it for
systemd for now then.

Regards
Paul

[-- Attachment #2: Type: text/html, Size: 584 bytes --]

Re: GLOB_BRACE

[Rich Felker]

On Sun, Sep 15, 2013 at 10:57:20PM +0200, Paul Schutte wrote:
> Hi,
> 
> I have hit the next stumbling block (show stopper):
> 
> src/shared/util.c: In function 'glob_exists':
> src/shared/util.c:4376:36: error: 'GLOB_BRACE' undeclared (first use in
> this function)
> src/shared/util.c:4376:36: note: each undeclared identifier is reported
> only once for each function it appears in
> 
> 
> I see this is and non-standard posix extension. I guess that is it for
> systemd for now then.

The correct action for programs that need GNU functionality like this
is to include their own copy of the GNU function (usually as part of
gnulib) and use it if the system does not have it.

In the case of GLOB_BRACE and the other GNU extensions to
glob/fnmatch, it's not clear to me that they admit an efficient
in-place implementation, and I doubt they do. That's why musl does not
support them.

Rich

Re: GLOB_BRACE

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Hi Rich,

Thanks. Just wanted to get confirmation in case I missed something.

I guess systemd was written with only linux in mind and therefore used a
lot of glibc specific stuff.

I found a lot of other portability problems since sending this message.

It won't be easy to make systemd work (To me in any case).

Regards
Paul



On Mon, Sep 16, 2013 at 2:50 PM, Rich Felker <dalias@aerifal.cx> wrote:

> On Sun, Sep 15, 2013 at 10:57:20PM +0200, Paul Schutte wrote:
> > Hi,
> >
> > I have hit the next stumbling block (show stopper):
> >
> > src/shared/util.c: In function 'glob_exists':
> > src/shared/util.c:4376:36: error: 'GLOB_BRACE' undeclared (first use in
> > this function)
> > src/shared/util.c:4376:36: note: each undeclared identifier is reported
> > only once for each function it appears in
> >
> >
> > I see this is and non-standard posix extension. I guess that is it for
> > systemd for now then.
>
> The correct action for programs that need GNU functionality like this
> is to include their own copy of the GNU function (usually as part of
> gnulib) and use it if the system does not have it.
>
> In the case of GLOB_BRACE and the other GNU extensions to
> glob/fnmatch, it's not clear to me that they admit an efficient
> in-place implementation, and I doubt they do. That's why musl does not
> support them.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2048 bytes --]

Re: GLOB_BRACE

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On 16 Sep 2013 14:41, "Paul Schutte" <sjpschutte@gmail.com> wrote:
>
> Hi Rich,
>
> Thanks. Just wanted to get confirmation in case I missed something.
>
> I guess systemd was written with only linux in mind and therefore used a
lot of glibc specific stuff.
>
> I found a lot of other portability problems since sending this message.
>
> It won't be easy to make systemd work (To me in any case).

Given that portability is a stated non goal getting anything upstream may
be difficult for this project...

> Regards
> Paul
>
>
>
> On Mon, Sep 16, 2013 at 2:50 PM, Rich Felker <dalias@aerifal.cx> wrote:
>>
>> On Sun, Sep 15, 2013 at 10:57:20PM +0200, Paul Schutte wrote:
>> > Hi,
>> >
>> > I have hit the next stumbling block (show stopper):
>> >
>> > src/shared/util.c: In function 'glob_exists':
>> > src/shared/util.c:4376:36: error: 'GLOB_BRACE' undeclared (first use in
>> > this function)
>> > src/shared/util.c:4376:36: note: each undeclared identifier is reported
>> > only once for each function it appears in
>> >
>> >
>> > I see this is and non-standard posix extension. I guess that is it for
>> > systemd for now then.
>>
>> The correct action for programs that need GNU functionality like this
>> is to include their own copy of the GNU function (usually as part of
>> gnulib) and use it if the system does not have it.
>>
>> In the case of GLOB_BRACE and the other GNU extensions to
>> glob/fnmatch, it's not clear to me that they admit an efficient
>> in-place implementation, and I doubt they do. That's why musl does not
>> support them.
>>
>> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 2190 bytes --]

Re: GLOB_BRACE

[Luca Barbato]

On 16/09/13 15:40, Paul Schutte wrote:
> Hi Rich,
> 
> Thanks. Just wanted to get confirmation in case I missed something.
> 
> I guess systemd was written with only linux in mind and therefore used a
> lot of glibc specific stuff.

Pity linux isn't glibc-2.16+ I guess...

> I found a lot of other portability problems since sending this message.

If you need just the device manager eudev provides a portable udev
implementation.

lu

Re: GLOB_BRACE

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Thanks.

This looks very promising.


On Mon, Sep 16, 2013 at 3:51 PM, Luca Barbato <lu_zero@gentoo.org> wrote:

> On 16/09/13 15:40, Paul Schutte wrote:
> > Hi Rich,
> >
> > Thanks. Just wanted to get confirmation in case I missed something.
> >
> > I guess systemd was written with only linux in mind and therefore used a
> > lot of glibc specific stuff.
>
> Pity linux isn't glibc-2.16+ I guess...
>
> > I found a lot of other portability problems since sending this message.
>
> If you need just the device manager eudev provides a portable udev
> implementation.
>
> lu
>

[-- Attachment #2: Type: text/html, Size: 971 bytes --]

Re: GLOB_BRACE

[Rob Landley]

On 09/16/2013 08:40:53 AM, Paul Schutte wrote:
> Hi Rich,
> 
> Thanks. Just wanted to get confirmation in case I missed something.
> 
> I guess systemd was written with only linux in mind and therefore  
> used a
> lot of glibc specific stuff.
> 
> I found a lot of other portability problems since sending this  
> message.
> 
> It won't be easy to make systemd work (To me in any case).

systemd is the second coming of devfsd. A lot of us are waiting for it  
to blow over.

If you use Gnu Gnome, and actually want to upgrade to the current  
version, systemd is required. If not, it isn't really.

Rob

Re: GLOB_BRACE

[Luca Barbato]

On 23/09/13 16:08, Rob Landley wrote:
> systemd is the second coming of devfsd. A lot of us are waiting for it
> to blow over.

Given the economic and PR support it won't blow over easily if
alternatives on par on the PR side won't appear.

Keep in mind that pigs can fly just nicely if propelled adequately. The
landing could be problematic though.

lu

Re: GLOB_BRACE

[Rich Felker]

On Mon, Sep 23, 2013 at 04:35:25PM +0200, Luca Barbato wrote:
> On 23/09/13 16:08, Rob Landley wrote:
> > systemd is the second coming of devfsd. A lot of us are waiting for it
> > to blow over.
> 
> Given the economic and PR support it won't blow over easily if
> alternatives on par on the PR side won't appear.
> 
> Keep in mind that pigs can fly just nicely if propelled adequately. The
> landing could be problematic though.

The problem is that, for the audience it's designed for, systemd is a
big step up. Previously they were using hideous bash scripts full of
pidfile races for starting and stopping services, etc.

For us, things are easy. systemd is not meeting a need or doing
anything better than the much simpler, more reliable tools we already
have. But unfortunately there's a risk of it getting imposed on people
who don't need it, and drastically blocking hopes to make the core
system robust, because it's hard to do better than systemd in its own
area, and there are commercially-relevant groups who care about that
area. And of course you have the issue that it's absorbing other
critical components like udev that everybody needs and making it
impossible to use them without systemd.

Rich

Re: GLOB_BRACE

[Rob Landley]

On 09/23/2013 09:35:25 AM, Luca Barbato wrote:
> On 23/09/13 16:08, Rob Landley wrote:
> > systemd is the second coming of devfsd. A lot of us are waiting for  
> it
> > to blow over.
> 
> Given the economic and PR support it won't blow over easily if
> alternatives on par on the PR side won't appear.

Exact same argument applied to Windows.

> Keep in mind that pigs can fly just nicely if propelled adequately.  
> The
> landing could be problematic though.

Mainframe -> minicomputer -> microcomputer -> smartphone. Arguing about  
how Red Hat Enterprise does it today is like arguing over how the VAX  
did it circa 1991.

Linux on the desktop didn't happen. Past tense. There are a billion  
android devices in use today. The new iPhone is explicitly a desktop  
replacement with a 64 bit processor, support for bluetooth mice and  
keyboards, and airplay to put the display on any HDTV:

   http://www.cringely.com/2013/09/19/the-secret-of-ios-7/

Android's not far behind. All we have to do is prevent systemd from  
being adopted by Android and Lennart's Hairball can get kicked up into  
the server space with the previous generation of hardware like Cobol  
before it, where we don't have to care unless we want to be our  
generation's version of punched card job control wranglers for the  
money.

Rob

Re: GLOB_BRACE

[Kurt H Maier]

Quoting Rich Felker <dalias@aerifal.cx>:

> The problem is that, for the audience it's designed for, systemd is a
> big step up. Previously they were using hideous bash scripts full of
> pidfile races for starting and stopping services, etc.
>


The correct answer would have been to fix the services, rather than invent
a more complicated bandaid to cover the problem.  Unfortunately Red Hat in
particular has determined a one-size-fits all approach is best, and then
focused their engineering on desktop-oriented software, which leaves us with
ugly hacks like initrd and systemd even on systems for which those bandaids
are wholly inappropriate.

We're stuck with systemd at least for the lifespan of RHEL7, although I
expect workarounds to emerge very quickly around the time RHEL6 nears EOL.

khm

Re: GLOB_BRACE

[Luca Barbato]

On 23/09/13 17:03, Rich Felker wrote:
> The problem is that, for the audience it's designed for, systemd is a
> big step up. Previously they were using hideous bash scripts full of
> pidfile races for starting and stopping services, etc.

That part is getting fun since nowadays to get something done you have
to use bash again even within units since whoever thought about the
format didn't consider some real world needs ...

> For us, things are easy. systemd is not meeting a need or doing
> anything better than the much simpler, more reliable tools we already
> have.

Our fault for not promoting them well enough I guess...

> But unfortunately there's a risk of it getting imposed on people
> who don't need it, and drastically blocking hopes to make the core
> system robust, because it's hard to do better than systemd in its own
> area, and there are commercially-relevant groups who care about that
> area.

Yeah, better PR is all the alternative lacks.

> And of course you have the issue that it's absorbing other
> critical components like udev that everybody needs and making it
> impossible to use them without systemd.

Luckily eudev solved that problem for now (I'm starting to wonder if who
ventured to say that the project got so much bashing for this strategic
reason...)

lu

Re: GLOB_BRACE

[Kurt H Maier]

Quoting Rob Landley <rob@landley.net>:
>
> Android's not far behind. All we have to do is prevent systemd from
> being adopted by Android and Lennart's Hairball can get kicked up into
> the server space with the previous generation of hardware like Cobol
> before it, where we don't have to care unless we want to be our
> generation's version of punched card job control wranglers for the
> money.
>

I'm not sure a gigantic java bloodfest is preferable.  Android is, if
anything, more Red Hat than Red Hat, with the added disadvantage that
half the system services are implemented in a badly-envisioned million-
daemon dystopia.  The android development world is a copy-paste
nightmare of Biblical proportions.  It's bad enough that RHELisms have
infected the space I live in -- when they start distributing HPC
software in .apk packages I'm checking out.

khm

Re: GLOB_BRACE

[Rich Felker]

On Mon, Sep 23, 2013 at 10:18:12AM -0500, Rob Landley wrote:
> On 09/23/2013 09:35:25 AM, Luca Barbato wrote:
> >On 23/09/13 16:08, Rob Landley wrote:
> >> systemd is the second coming of devfsd. A lot of us are waiting
> >for it
> >> to blow over.
> >
> >Given the economic and PR support it won't blow over easily if
> >alternatives on par on the PR side won't appear.
> 
> Exact same argument applied to Windows.

And Windows hasn't "blown over". It's become arguably irrelevant
percentage-wise because the scope of the 'market' has vastly grown,
but in terms of absolute numbers it's still there, and it's still
critical to most of the content-production that takes place.

It's fine if you want to say you don't care about this now-niche
market, but that doesn't solve the problem for people who are still
dependent on it (which is still a fairly large portion of the
computer-using population, even if only a small portion of the number
of computers).

> >Keep in mind that pigs can fly just nicely if propelled
> >adequately. The
> >landing could be problematic though.
> 
> Mainframe -> minicomputer -> microcomputer -> smartphone. Arguing
> about how Red Hat Enterprise does it today is like arguing over how
> the VAX did it circa 1991.
> 
> Linux on the desktop didn't happen. Past tense. There are a billion
> android devices in use today. The new iPhone is explicitly a desktop
> replacement with a 64 bit processor, support for bluetooth mice and
> keyboards, and airplay to put the display on any HDTV:
> 
>   http://www.cringely.com/2013/09/19/the-secret-of-ios-7/

The iPhone doesn't even have a model for storing data locally in a way
that's sharable between applications. Yes, we're moving in the
direction you describe, but it's going to (1) take a bit longer, and
(2) be full of really bad solutions from all the major commercial
players.

> Android's not far behind. All we have to do is prevent systemd from
> being adopted by Android and Lennart's Hairball can get kicked up
> into the server space with the previous generation of hardware like
> Cobol before it, where we don't have to care unless we want to be
> our generation's version of punched card job control wranglers for
> the money.

The problem is that we do care about server space. The naive version
of your analogy with "mainframe -> mini -> ..." breaks down in that
this time, it's not really the old technology and problems being
pushed up to the servespace. Instead, the serverspace is undergoing
its own major change to something new; in buzzword-space, this is
called "the cloud". Even if it's similar hardware to what was in use
on "the desktop" in the past (even this is debatable; the only
similarity is really the ISA, x86, and parts of the associated
peripheral architecture) the deployment model is vastly different.

Part of this is the pushing of the thin client model on devices, which
probably makes sense, from lots of standpoints: power-consumption,
avoiding malware, protecting data against device loss/theft, etc. But
it also means that development for mobile devices will probably
continue to entail development of corresponding server-side
components.

Rich

Re: GLOB_BRACE

[Rob Landley]

On 09/23/2013 10:54:55 AM, Rich Felker wrote:
> On Mon, Sep 23, 2013 at 10:18:12AM -0500, Rob Landley wrote:
> > On 09/23/2013 09:35:25 AM, Luca Barbato wrote:
> > >On 23/09/13 16:08, Rob Landley wrote:
> > >> systemd is the second coming of devfsd. A lot of us are waiting
> > >for it
> > >> to blow over.
> > >
> > >Given the economic and PR support it won't blow over easily if
> > >alternatives on par on the PR side won't appear.
> >
> > Exact same argument applied to Windows.
> 
> And Windows hasn't "blown over".

Sure. But it wasn't a reason to stop doing Linux either.

> It's become arguably irrelevant
> percentage-wise because the scope of the 'market' has vastly grown,
> but in terms of absolute numbers it's still there, and it's still
> critical to most of the content-production that takes place.
> 
> It's fine if you want to say you don't care about this now-niche
> market, but that doesn't solve the problem for people who are still
> dependent on it (which is still a fairly large portion of the
> computer-using population, even if only a small portion of the number
> of computers).

Server systems migrated from glibc to musl but with systemd seems like  
a fairly small niche, but if it interests you...

> > >Keep in mind that pigs can fly just nicely if propelled
> > >adequately. The
> > >landing could be problematic though.
> >
> > Mainframe -> minicomputer -> microcomputer -> smartphone. Arguing
> > about how Red Hat Enterprise does it today is like arguing over how
> > the VAX did it circa 1991.
> >
> > Linux on the desktop didn't happen. Past tense. There are a billion
> > android devices in use today. The new iPhone is explicitly a desktop
> > replacement with a 64 bit processor, support for bluetooth mice and
> > keyboards, and airplay to put the display on any HDTV:
> >
> >   http://www.cringely.com/2013/09/19/the-secret-of-ios-7/
> 
> The iPhone doesn't even have a model for storing data locally in a way
> that's sharable between applications. Yes, we're moving in the
> direction you describe, but it's going to (1) take a bit longer, and
> (2) be full of really bad solutions from all the major commercial
> players.

Agreed. Although the number of failed X11 thin clients in the 1990's  
was kind of hilarious.

http://en.wikipedia.org/wiki/X_terminal
http://news.cnet.com/Ellison-resurrects-network-computer/2100-1001_3-233137.html

People have been trying to get rid of local storage and have dumb  
terminals for something like 30 years. It's been 5 years away all that  
time.

*shrug* I often use my android phone for is as a convenient USB stick  
via the charger cable. How this is programmed is still up in the air,  
but the hardware's there.

> > Android's not far behind. All we have to do is prevent systemd from
> > being adopted by Android and Lennart's Hairball can get kicked up
> > into the server space with the previous generation of hardware like
> > Cobol before it, where we don't have to care unless we want to be
> > our generation's version of punched card job control wranglers for
> > the money.
> 
> The problem is that we do care about server space. The naive version
> of your analogy with "mainframe -> mini -> ..." breaks down in that
> this time, it's not really the old technology and problems being
> pushed up to the servespace. Instead, the serverspace is undergoing
> its own major change to something new; in buzzword-space, this is
> called "the cloud".

I thought "the cloud" was the name of the NSA's server?

> Even if it's similar hardware to what was in use
> on "the desktop" in the past (even this is debatable; the only
> similarity is really the ISA, x86, and parts of the associated
> peripheral architecture) the deployment model is vastly different.
> 
> Part of this is the pushing of the thin client model on devices, which
> probably makes sense, from lots of standpoints: power-consumption,
> avoiding malware, protecting data against device loss/theft, etc. But
> it also means that development for mobile devices will probably
> continue to entail development of corresponding server-side
> components.

Have they solved spectrum crunch yet?

http://www.youtube.com/watch?v=GuqmKg6QQTw

*shrug* Within IBM, one of the main uses of the original PC was to run  
a tn3270 client in software. But the PC grew legs, I still expect the  
phone to do so. Transition's likely to take a while, but expecting  
conventional linux on the desktop to suddenly matter more? Well, at  
least we're making a unified effort:

https://lwn.net/Articles/564369/
http://venturebeat.com/2013/09/04/mozilla-will-give-you-a-free-firefox-phone-if-you-port-your-app/
http://www.indystar.com/article/20130923/BUSINESS/309230002/Google-banking-new-Chromebook-lineup
http://dot.kde.org/2013/09/05/plasma-active-4-ready-when-you-are

> Rich

Rob

Re: GLOB_BRACE

[Rich Felker]

On Mon, Sep 23, 2013 at 12:22:28PM -0500, Rob Landley wrote:
> >It's become arguably irrelevant
> >percentage-wise because the scope of the 'market' has vastly grown,
> >but in terms of absolute numbers it's still there, and it's still
> >critical to most of the content-production that takes place.
> >
> >It's fine if you want to say you don't care about this now-niche
> >market, but that doesn't solve the problem for people who are still
> >dependent on it (which is still a fairly large portion of the
> >computer-using population, even if only a small portion of the number
> >of computers).
> 
> Server systems migrated from glibc to musl but with systemd seems
> like a fairly small niche, but if it interests you...

Well I was thinking of the class "server systems migrated to musl",
without anything about systemd, which is a very interesting class
since musl potentially allows for much smaller (in disk and ram needs)
virtual environments. Think from a standpoint of having 50x as many
geographically-diverse server nodes each using 1/50 the resources, at
the same cost.

> People have been trying to get rid of local storage and have dumb
> terminals for something like 30 years. It's been 5 years away all
> that time.
> 
> *shrug* I often use my android phone for is as a convenient USB
> stick via the charger cable. How this is programmed is still up in
> the air, but the hardware's there.

This is pretty problematic in terms of security with Android, but it
could be made very nice with a proper OS. Think of something like
this: when you plug in the device, a menu pops up on the device giving
you several choices:

- New sandbox virtual disk, initially empty
- Existing sandbox virtual disk, read-only
- Existing sandbox virtual disk, read-write
- Main storage, read-only
- Main storage, read-write

Of course there are a lot more things that could be done to make this
more user-friendly and flexible; it might even make sense to
virtualize the fs image presented on the virtual mass storage device
so as to allow the mobile OS to log/audit the blocks accessed, changes
made, etc. and report suspicious activity to the user.

> >> Android's not far behind. All we have to do is prevent systemd from
> >> being adopted by Android and Lennart's Hairball can get kicked up
> >> into the server space with the previous generation of hardware like
> >> Cobol before it, where we don't have to care unless we want to be
> >> our generation's version of punched card job control wranglers for
> >> the money.
> >
> >The problem is that we do care about server space. The naive version
> >of your analogy with "mainframe -> mini -> ..." breaks down in that
> >this time, it's not really the old technology and problems being
> >pushed up to the servespace. Instead, the serverspace is undergoing
> >its own major change to something new; in buzzword-space, this is
> >called "the cloud".
> 
> I thought "the cloud" was the name of the NSA's server?

It's pretty unclear what it actually means, but the elements I was
thinking of are use of CDN's, distributed virtual servers, and
online/distributed data storage.

Rich

Re: GLOB_BRACE

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

"For us, things are easy. systemd is not meeting a need or doing
anything better than the much simpler, more reliable tools we already
have."

Can you guys maybe point me in the direction of these tools please ?


On Mon, Sep 23, 2013 at 5:03 PM, Rich Felker <dalias@aerifal.cx> wrote:

> On Mon, Sep 23, 2013 at 04:35:25PM +0200, Luca Barbato wrote:
> > On 23/09/13 16:08, Rob Landley wrote:
> > > systemd is the second coming of devfsd. A lot of us are waiting for it
> > > to blow over.
> >
> > Given the economic and PR support it won't blow over easily if
> > alternatives on par on the PR side won't appear.
> >
> > Keep in mind that pigs can fly just nicely if propelled adequately. The
> > landing could be problematic though.
>
> The problem is that, for the audience it's designed for, systemd is a
> big step up. Previously they were using hideous bash scripts full of
> pidfile races for starting and stopping services, etc.
>
> For us, things are easy. systemd is not meeting a need or doing
> anything better than the much simpler, more reliable tools we already
> have. But unfortunately there's a risk of it getting imposed on people
> who don't need it, and drastically blocking hopes to make the core
> system robust, because it's hard to do better than systemd in its own
> area, and there are commercially-relevant groups who care about that
> area. And of course you have the issue that it's absorbing other
> critical components like udev that everybody needs and making it
> impossible to use them without systemd.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2084 bytes --]

Re: GLOB_BRACE

[Rich Felker]

On Thu, Sep 26, 2013 at 12:46:33AM +0200, Paul Schutte wrote:
> "For us, things are easy. systemd is not meeting a need or doing
> anything better than the much simpler, more reliable tools we already
> have."
> 
> Can you guys maybe point me in the direction of these tools please ?

The one I use is called a flat shell script, of the form:

inetd &
dropbear &
...

and it has the whole system up before the monitor can sync to the
video card's signal. There are fancier options too, still without
being as slow and bloated as major distros' sysvinit-style init
scripts or systemd.

Rich

Re: GLOB_BRACE

[Luca Barbato]

On 26/09/13 00:46, Paul Schutte wrote:
> "For us, things are easy. systemd is not meeting a need or doing
> anything better than the much simpler, more reliable tools we already
> have."
> 
> Can you guys maybe point me in the direction of these tools please ?

http://smarden.org/runit/ (process supervising and init replacement)
http://wiki.gentoo.org/wiki/Project:Eudev (device management)
http://wiki.gentoo.org/wiki/Mdev (device management, the other way)
http://wiki.gentoo.org/wiki/OpenRC (init coordination, runs everywhere)

Depending on the part of systemd you care for.

Once I have more time and/or people/resources I might overhaul
consolekit as seatd to provide an alternative logind with a funnier name.

lu

Re: GLOB_BRACE

[Daniel Cegiełka]

and runit successor (by Felix von Leitner):

http://www.fefe.de/minit/
http://www.fefe.de/minit/minit-linux-kongress2004.pdf

Daniel

Re: GLOB_BRACE

[Rich Felker]

On Thu, Sep 26, 2013 at 05:35:42AM +0200, Luca Barbato wrote:
> On 26/09/13 00:46, Paul Schutte wrote:
> > "For us, things are easy. systemd is not meeting a need or doing
> > anything better than the much simpler, more reliable tools we already
> > have."
> > 
> > Can you guys maybe point me in the direction of these tools please ?
> 
> http://smarden.org/runit/ (process supervising and init replacement)
> http://wiki.gentoo.org/wiki/Project:Eudev (device management)
> http://wiki.gentoo.org/wiki/Mdev (device management, the other way)
> http://wiki.gentoo.org/wiki/OpenRC (init coordination, runs everywhere)
> 
> Depending on the part of systemd you care for.
> 
> Once I have more time and/or people/resources I might overhaul
> consolekit as seatd to provide an alternative logind with a funnier name.

It should be noted that runit, and the runit replacements I've seen,
are still quite bloated compared to what they actually could/should
be, and are probably also lacking in robustness. I see them more as
"the right direction" than the end goal.

Rich

Re: GLOB_BRACE

[Daniel Cegiełka]

2013/9/26 Rich Felker <dalias@aerifal.cx>:

> It should be noted that runit, and the runit replacements I've seen,
> are still quite bloated compared to what they actually could/should
> be, and are probably also lacking in robustness. I see them more as
> "the right direction" than the end goal.
>
> Rich

And what is your opinion about minit? It's written by runit author (fefe).

Daniel

Re: GLOB_BRACE

[Rich Felker]

On Thu, Sep 26, 2013 at 08:30:20PM +0200, Daniel Cegiełka wrote:
> 2013/9/26 Rich Felker <dalias@aerifal.cx>:
> 
> > It should be noted that runit, and the runit replacements I've seen,
> > are still quite bloated compared to what they actually could/should
> > be, and are probably also lacking in robustness. I see them more as
> > "the right direction" than the end goal.
> >
> > Rich
> 
> And what is your opinion about minit? It's written by runit author (fefe).

I haven't read it, but I've never seen a piece of code by fefe that
had anything resembling robust error handling. (My main experience
reading his code is dietlibc though, so maybe some of his other stuff
is different.)

Rich

Re: GLOB_BRACE

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

@Rich

Referring to your description:

http://www.openwall.com/lists/musl/2012/06/10/23

"I have
a 22-line (C) init program that does nothing but run the boot script
and reap orphaned zombies, and a 34-line (C) program that repeatedly
re-runs a program in a new session every time it exits. The latter,
combined with a 14-line (shell script) getty program, is sufficient to
handle all console logins.
"

it's a bit more then 22 LOC :)

Daniel

[-- Attachment #2: init.c --]
[-- Type: text/x-csrc, Size: 1356 bytes --]

/*
 * init.c version 20130705
 * Daniel Cegielka
 * Public domain.
 */

#include <fcntl.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/reboot.h>
#include <linux/kd.h>

static void
sigchild(int sig)
{
	while(waitpid(-1, NULL, WNOHANG) > 0);
}

static void
openconsole(void)
{
	int fd;

	if((fd = open("/dev/console", O_RDWR|O_NOCTTY)) >= 0){
		dup2(fd, 0);
		dup2(fd, 1);
		dup2(fd, 2);
		if(fd > 2)
			close(fd);
	}
}

int
main(int argc, char **argv)
{
	int i, fd, l;
	struct sigaction sa;
	pid_t t;

	if(getpid() != 1)
		return 1;
	for(i = 0, l = 0; i < argc; i++)
		l = strlen(argv[i]) + 1;
	if(l > 1){
		memset(argv[0], 0, l);
		strncpy(argv[0], "init", l - 1);
	}
	for(i = 1; i < NSIG; i++)
		if(i != SIGCHLD)
			(void)signal(i, SIG_IGN);
	reboot(RB_DISABLE_CAD);
	if((fd = open("/dev/console", O_RDWR|O_NOCTTY)) >= 0){
		ioctl(fd, KDSIGACCEPT, SIGWINCH);
		close(fd);
	} else
		ioctl(0, KDSIGACCEPT, SIGWINCH);
	for(i = 0; i < 3; i++){
		close(i);
		open("/dev/null", O_RDWR, 0);
	}
	if(!fork()){
		setsid();
		openconsole();
		tcsetpgrp(0, getpgrp());
		execl("/bin/sh", "sh", "/etc/rc", NULL);
		while(waitpid(t, NULL, 0) != t);
	}
	sigemptyset(&sa.sa_mask);
	sa.sa_sigaction = 0;
	sa.sa_flags = SA_RESTART|SA_NOCLDSTOP;
	sa.sa_handler = sigchild;
	sigaction(SIGCHLD, &sa, 0);
	for(;;)
		pause();
}

Re: GLOB_BRACE

[Rich Felker]

On Thu, Sep 26, 2013 at 08:50:33PM +0200, Daniel Cegiełka wrote:
> @Rich
> 
> Referring to your description:
> 
> http://www.openwall.com/lists/musl/2012/06/10/23
> 
> "I have
> a 22-line (C) init program that does nothing but run the boot script
> and reap orphaned zombies, and a 34-line (C) program that repeatedly
> re-runs a program in a new session every time it exits. The latter,
> combined with a 14-line (shell script) getty program, is sufficient to
> handle all console logins.
> "
> 
> it's a bit more then 22 LOC :)

Yeah, yours does a few more things, and does so somewhat less
efficiently.

> static void
> sigchild(int sig)
> {
> 	while(waitpid(-1, NULL, WNOHANG) > 0);
> }

Not needed.

> static void
> openconsole(void)
> {
> 	int fd;
> 
> 	if((fd = open("/dev/console", O_RDWR|O_NOCTTY)) >= 0){
> 		dup2(fd, 0);
> 		dup2(fd, 1);
> 		dup2(fd, 2);
> 		if(fd > 2)
> 			close(fd);
> 	}
> }

Unclear what this is needed for. Normally init starts on the console
anyway, and if it doesn't, why would you want to force it to use the
console instead of whatever stdin/out/err it started with?

> int
> main(int argc, char **argv)
> {
> 	int i, fd, l;
> 	struct sigaction sa;
> 	pid_t t;
> 
> 	if(getpid() != 1)
> 		return 1;
> 	for(i = 0, l = 0; i < argc; i++)
> 		l = strlen(argv[i]) + 1;
> 	if(l > 1){
> 		memset(argv[0], 0, l);
> 		strncpy(argv[0], "init", l - 1);
> 	}
> 	for(i = 1; i < NSIG; i++)
> 		if(i != SIGCHLD)
> 			(void)signal(i, SIG_IGN);

Why are you ignoring signals rather than blocking them? It's more work
and harder to undo before running the rc script (and you don't seem to
be undoing it).

> 	reboot(RB_DISABLE_CAD);
> 	if((fd = open("/dev/console", O_RDWR|O_NOCTTY)) >= 0){
> 		ioctl(fd, KDSIGACCEPT, SIGWINCH);

What does this do?

> 	if(!fork()){
> 		setsid();
> 		openconsole();
> 		tcsetpgrp(0, getpgrp());
> 		execl("/bin/sh", "sh", "/etc/rc", NULL);
> 		while(waitpid(t, NULL, 0) != t);
> 	}
> 	sigemptyset(&sa.sa_mask);
> 	sa.sa_sigaction = 0;
> 	sa.sa_flags = SA_RESTART|SA_NOCLDSTOP;
> 	sa.sa_handler = sigchild;
> 	sigaction(SIGCHLD, &sa, 0);
> 	for(;;)
> 		pause();

Instead use:

	for (;;) wait(&status);

and you don't have to handle SIGCHLD.

Rich

Re: GLOB_BRACE

[John Spencer]

On 09/26/2013 08:50 PM, Daniel Cegiełka wrote:
> @Rich
>
> Referring to your description:
>
> http://www.openwall.com/lists/musl/2012/06/10/23
>
> "I have
> a 22-line (C) init program that does nothing but run the boot script
> and reap orphaned zombies, and a 34-line (C) program that repeatedly
> re-runs a program in a new session every time it exits. The latter,
> combined with a 14-line (shell script) getty program, is sufficient to
> handle all console logins.
> "

for those who're curious, it's archived here
  https://gist.github.com/rofl0r/6168719

Re: GLOB_BRACE

[Daniel Cegiełka]

@Rich
Thank you, I will try to fix it. It was first time I started to write
init and I had no experience what is necessary. I just studied runit,
minit, ninit and others *init. Thank you again for your feedback.

Daniel

Re: GLOB_BRACE

[Rich Felker]

On Thu, Sep 26, 2013 at 09:10:21PM +0200, Daniel Cegiełka wrote:
> @Rich
> Thank you, I will try to fix it. It was first time I started to write
> init and I had no experience what is necessary. I just studied runit,
> minit, ninit and others *init. Thank you again for your feedback.

Not all of it was "fixes"; some was just comments. In particular I
don't know what the SIGWINCH stuff is for, nor whether there's any
good reason they're doing the console manipulation stuff. However, I
suspect even if that stuff is potentially useful, it would be better
(from the sense of flexibility) done from the rc script rather than
the init process.

Rich

Re: GLOB_BRACE

[Christian Neukirchen]

Rich Felker <dalias@aerifal.cx> writes:

> On Thu, Sep 26, 2013 at 05:35:42AM +0200, Luca Barbato wrote:
>> On 26/09/13 00:46, Paul Schutte wrote:
>> > "For us, things are easy. systemd is not meeting a need or doing
>> > anything better than the much simpler, more reliable tools we already
>> > have."
>> > 
>> > Can you guys maybe point me in the direction of these tools please ?
>> 
>> http://smarden.org/runit/ (process supervising and init replacement)
>> http://wiki.gentoo.org/wiki/Project:Eudev (device management)
>> http://wiki.gentoo.org/wiki/Mdev (device management, the other way)
>> http://wiki.gentoo.org/wiki/OpenRC (init coordination, runs everywhere)
>> 
>> Depending on the part of systemd you care for.
>> 
>> Once I have more time and/or people/resources I might overhaul
>> consolekit as seatd to provide an alternative logind with a funnier name.
>
> It should be noted that runit, and the runit replacements I've seen,
> are still quite bloated compared to what they actually could/should
> be, and are probably also lacking in robustness. I see them more as
> "the right direction" than the end goal.

runit.c (pid 1) has 346 loc, and the service supervisor runsv.c has 607
loc.  (Most of the code does error handling!)  They compile down to a
13k resp. 18k binary using musl.

I won't speak of runit alternatives, but runit certainly isn't bloated
and has been very robust in my experience.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: GLOB_BRACE

[Daniel Cegiełka]

2013/9/26 Rich Felker <dalias@aerifal.cx>:
> On Thu, Sep 26, 2013 at 09:10:21PM +0200, Daniel Cegiełka wrote:
>> @Rich
>> Thank you, I will try to fix it. It was first time I started to write
>> init and I had no experience what is necessary. I just studied runit,
>> minit, ninit and others *init. Thank you again for your feedback.
>
> Not all of it was "fixes"; some was just comments. In particular I
> don't know what the SIGWINCH stuff is for, nor whether there's any
> good reason they're doing the console manipulation stuff. However, I
> suspect even if that stuff is potentially useful, it would be better
> (from the sense of flexibility) done from the rc script rather than
> the init process.

In Nicholas Kain's ninit  there are similar things - in other
implementations also seen such stuff.

http://kain.us/nk/projects/

>
> Rich

Re: GLOB_BRACE

[Daniel Cegiełka]

2013/9/26 John Spencer <maillist-musl@barfooze.de>:

> for those who're curious, it's archived here
>  https://gist.github.com/rofl0r/6168719

Is this implementation work? I can't boot with...

Daniel

Re: GLOB_BRACE

[Daniel Cegiełka]

2013/9/26 Daniel Cegiełka <daniel.cegielka@gmail.com>:
> 2013/9/26 John Spencer <maillist-musl@barfooze.de>:
>
>> for those who're curious, it's archived here
>>  https://gist.github.com/rofl0r/6168719
>
> Is this implementation work? I can't boot with...

ok, it works :)
chmod +x /etc/rc

thx

Re: GLOB_BRACE

[Anthony G. Basile]

On 09/26/2013 04:41 PM, Daniel Cegiełka wrote:
> 2013/9/26 Daniel Cegiełka <daniel.cegielka@gmail.com>:
>> 2013/9/26 John Spencer <maillist-musl@barfooze.de>:
>>
>>> for those who're curious, it's archived here
>>>   https://gist.github.com/rofl0r/6168719
>>
>> Is this implementation work? I can't boot with...
>
> ok, it works :)
> chmod +x /etc/rc
>
> thx
>

If this is mature enough, I can write a gentoo ebuild for it and put it 
on the gentoo portage tree as a replacement for sysvinit for a musl 
system.  Once of the major blocks to a full gentoo stage3 is sysvinit. 
Also openrc doesn't build on musl and its still required for some 
fundamental gentoo pieces, even though it competes with systemd.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: GLOB_BRACE

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

2013/9/27 Anthony G. Basile <basile@opensource.dyc.edu>:
> On 09/26/2013 04:41 PM, Daniel Cegiełka wrote:

> If this is mature enough, I can write a gentoo ebuild for it and put it on
> the gentoo portage tree as a replacement for sysvinit for a musl system.
> Once of the major blocks to a full gentoo stage3 is sysvinit. Also openrc
> doesn't build on musl and its still required for some fundamental gentoo
> pieces, even though it competes with systemd.

Anthony, sysvinit and openrc work with musl. Unfortunately, I think I
lost my old openrc port :/

sysvinit.tar - port based on Gentoo, Owl and musl patches (btw. it's
not ebuild!).

best regards,
Daniel

[-- Attachment #2: sysvinit.tar --]
[-- Type: application/x-tar, Size: 51200 bytes --]

[-- Attachment #3: sysvinit_build.log --]
[-- Type: application/octet-stream, Size: 6681 bytes --]

Re: GLOB_BRACE

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

2013/9/27 Anthony G. Basile <basile@opensource.dyc.edu>:

> Also openrc
> doesn't build on musl and its still required for some fundamental gentoo
> pieces, even though it competes with systemd.

Could you describe compilation errors (temp/build.log)? Try patches...

Daniel

[-- Attachment #2: openrc_DECLS.diff --]
[-- Type: application/octet-stream, Size: 1058 bytes --]

diff -urN openrc-0.9.8.4.orig//src/libeinfo/einfo.h openrc-0.9.8.4/src/libeinfo/einfo.h
--- openrc-0.9.8.4.orig//src/libeinfo/einfo.h	2012-08-16 12:10:45.164407735 +0200
+++ openrc-0.9.8.4/src/libeinfo/einfo.h	2012-08-16 12:11:12.779059479 +0200
@@ -48,8 +48,6 @@
 # endif
 #endif
 
-__BEGIN_DECLS
-
 /*! @brief Color types to use */
 typedef enum
 {
@@ -140,5 +138,4 @@
 /*! @brief Prefix each einfo line with something */
 void eprefix(const char * EINFO_RESTRICT);
 
-__END_DECLS
 #endif
diff -urN openrc-0.9.8.4.orig//src/librc/rc.h.in openrc-0.9.8.4/src/librc/rc.h.in
--- openrc-0.9.8.4.orig//src/librc/rc.h.in	2012-08-16 12:10:45.168407539 +0200
+++ openrc-0.9.8.4/src/librc/rc.h.in	2012-08-16 12:12:17.691890180 +0200
@@ -31,8 +31,6 @@
 #include <stdbool.h>
 #include <stdio.h>
 
-__BEGIN_DECLS
-
 #define RC_SYSCONFDIR		"@SYSCONFDIR@"
 #define RC_LIBDIR               "@PREFIX@/@LIB@/rc"
 #define RC_LIBEXECDIR           "@LIBEXECDIR@"
@@ -551,5 +549,4 @@
  * we have our own */
 ssize_t rc_getline(char **, size_t *, FILE *);
 
-__END_DECLS
 #endif

[-- Attachment #3: strlcat_strlcpy.diff --]
[-- Type: application/octet-stream, Size: 1206 bytes --]

diff -urN openrc-0.8.3.orig/src/libeinfo/libeinfo.c openrc-0.8.3/src/libeinfo/libeinfo.c
--- openrc-0.8.3.orig/src/libeinfo/libeinfo.c	2011-06-20 04:37:55.000000000 +0200
+++ openrc-0.8.3/src/libeinfo/libeinfo.c	2011-07-13 22:34:46.000000000 +0200
@@ -196,60 +196,6 @@
 };
 #endif
 
-/* strlcat and strlcpy are nice, shame glibc does not define them */
-#ifdef __GLIBC__
-#  if ! defined (__UCLIBC__) && ! defined (__dietlibc__)
-static size_t
-strlcat(char *dst, const char *src, size_t size)
-{
-	char *d = dst;
-	const char *s = src;
-	size_t src_n = size;
-	size_t dst_n;
-
-	while (src_n-- != 0 && *d != '\0')
-		d++;
-	dst_n = d - dst;
-	src_n = size - dst_n;
-
-	if (src_n == 0)
-		return dst_n + strlen(src);
-
-	while (*s != '\0') {
-		if (src_n != 1) {
-			*d++ = *s;
-			src_n--;
-		}
-		s++;
-	}
-	*d = '\0';
-
-	return dst_n + (s - src);
-}
-
-static size_t
-strlcpy(char *dst, const char *src, size_t size)
-{
-	const char *s = src;
-	size_t n = size;
-
-	if (n && --n)
-		do {
-			if (!(*dst++ = *src++))
-				break;
-		} while (--n);
-
-	if (!n) {
-		if (size)
-			*dst = '\0';
-		while (*src++);
-	}
-
-	return src - s - 1;
-}
-#  endif
-#endif
-
 static bool
 yesno(const char *value)
 {

Re: GLOB_BRACE

[Anthony G. Basile]

On 09/27/2013 09:06 AM, Daniel Cegiełka wrote:
> 2013/9/27 Anthony G. Basile <basile@opensource.dyc.edu>:
>
>> Also openrc
>> doesn't build on musl and its still required for some fundamental gentoo
>> pieces, even though it competes with systemd.
>
> Could you describe compilation errors (temp/build.log)? Try patches...
>
> Daniel
>

sysvinit was easy to fix, there was just a missing #include 
<sys/ttydefaults.h>.

openrc-0.11.8 is dying on the following:

x86_64-gentoo-linux-musl-gcc -I../includes -D_BSD_SOURCE 
-D_XOPEN_SOURCE=700  -DHAVE_TERMCAP -MM libeinfo.c > .depend
make[2]: Leaving directory 
`/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/libeinfo'
make[2]: Entering directory 
`/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/libeinfo'
x86_64-gentoo-linux-musl-gcc -fPIC -DPIC -I../includes -D_BSD_SOURCE 
-D_XOPEN_SOURCE=700  -DHAVE_TERMCAP -Os -pipe -fomit-frame-pointer 
-std=c99 -Wall -Wextra -Wimplicit -Wshadow -Wformat=2 
-Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn 
-Wmissing-format-attribute -Wnested-externs -Winline -Wwrite-strings 
-Wcast-align -Wcast-qual -Wpointer-arith -Wdeclaration-after-statement 
-Wsequence-point   -c libeinfo.c -o libeinfo.So
In file included from libeinfo.c:53:0:
einfo.h:54:1: error: expected '=', ',', ';', 'asm' or '__attribute__' 
before 'typedef'
einfo.h:65:1: warning: parameter names (without types) in function 
declaration [enabled by default]
einfo.h:124:20: error: unknown type name 'ECOLOR'
einfo.h:143:1: warning: data definition has no type or storage class 
[enabled by default]
einfo.h:143:1: warning: type defaults to 'int' in declaration of 
'__END_DECLS' [enabled by default]
In file included from libeinfo.c:54:0:


which can be fixed by commentin out __BEGIN_DECLS and __END_DECLS.


It then dies on

make[2]: Leaving directory 
`/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/librc'
make[2]: Entering directory 
`/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/librc'
cc -O2 -g -std=c99 -Wall -Wextra -Wimplicit -Wshadow -Wformat=2 
-Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn 
-Wmissing-format-attribute -Wnested-externs -Winline -Wwrite-strings 
-Wcast-align -Wcast-qual -Wpointer-arith -Wdeclaration-after-statement 
-Wsequence-point   -I../includes -D_BSD_SOURCE -D_XOPEN_SOURCE=700  -c 
librc.c -o librc.o
In file included from librc.h:67:0,
                  from librc.c:33:
rc.h:30:23: fatal error: sys/queue.h: No such file or directory
compilation terminated.



-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: GLOB_BRACE

[Rich Felker]

On Sun, Sep 29, 2013 at 05:51:16PM -0400, Anthony G. Basile wrote:
> On 09/27/2013 09:06 AM, Daniel Cegiełka wrote:
> >2013/9/27 Anthony G. Basile <basile@opensource.dyc.edu>:
> >
> >>Also openrc
> >>doesn't build on musl and its still required for some fundamental gentoo
> >>pieces, even though it competes with systemd.
> >
> >Could you describe compilation errors (temp/build.log)? Try patches...
> >
> >Daniel
> >
> 
> sysvinit was easy to fix, there was just a missing #include
> <sys/ttydefaults.h>.
> 
> openrc-0.11.8 is dying on the following:
> 
> x86_64-gentoo-linux-musl-gcc -I../includes -D_BSD_SOURCE
> -D_XOPEN_SOURCE=700  -DHAVE_TERMCAP -MM libeinfo.c > .depend
> make[2]: Leaving directory `/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/libeinfo'
> make[2]: Entering directory `/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/libeinfo'
> x86_64-gentoo-linux-musl-gcc -fPIC -DPIC -I../includes -D_BSD_SOURCE
> -D_XOPEN_SOURCE=700  -DHAVE_TERMCAP -Os -pipe -fomit-frame-pointer
> -std=c99 -Wall -Wextra -Wimplicit -Wshadow -Wformat=2
> -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn
> -Wmissing-format-attribute -Wnested-externs -Winline -Wwrite-strings
> -Wcast-align -Wcast-qual -Wpointer-arith
> -Wdeclaration-after-statement -Wsequence-point   -c libeinfo.c -o
> libeinfo.So
> In file included from libeinfo.c:53:0:
> einfo.h:54:1: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'typedef'
> einfo.h:65:1: warning: parameter names (without types) in function
> declaration [enabled by default]
> einfo.h:124:20: error: unknown type name 'ECOLOR'
> einfo.h:143:1: warning: data definition has no type or storage class
> [enabled by default]
> einfo.h:143:1: warning: type defaults to 'int' in declaration of
> '__END_DECLS' [enabled by default]
> In file included from libeinfo.c:54:0:
> 
> 
> which can be fixed by commentin out __BEGIN_DECLS and __END_DECLS.

Or, if the header is intended to be usable from C++, by adding the
correct #ifdef __cplusplus / extern "C" { / #endif, etc. blocks.

> It then dies on
> 
> make[2]: Leaving directory `/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/librc'
> make[2]: Entering directory `/var/tmp/portage/sys-apps/openrc-0.11.8/work/openrc-0.11.8/src/librc'
> cc -O2 -g -std=c99 -Wall -Wextra -Wimplicit -Wshadow -Wformat=2
> -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn
> -Wmissing-format-attribute -Wnested-externs -Winline -Wwrite-strings
> -Wcast-align -Wcast-qual -Wpointer-arith
> -Wdeclaration-after-statement -Wsequence-point   -I../includes
> -D_BSD_SOURCE -D_XOPEN_SOURCE=700  -c librc.c -o librc.o
> In file included from librc.h:67:0,
>                  from librc.c:33:
> rc.h:30:23: fatal error: sys/queue.h: No such file or directory
> compilation terminated.

sys/queue.h is a library in a header file. You can obtain a copy of it
from a glibc system (it's BSD licensed) or a number of other systems.
It's fully self-contained in the header file and there's no reason for
it to be part of libc.

Rich