* 'Proper' software writing
@ 2012-09-03 13:55 Igmar Palsenberg
2012-09-03 14:32 ` Szabolcs Nagy
2012-09-04 1:50 ` Rich Felker
0 siblings, 2 replies; 6+ messages in thread
From: Igmar Palsenberg @ 2012-09-03 13:55 UTC (permalink / raw)
To: Musl list
Hi,
When attempting to fix my own piece of software I've come to the
conclusing that writing somewhat portable software (glibc vs musl) is a
huge PITA.
I've ironed out most issues, but that left me with some questions :
- Why use _BSD_SOURCE and _GNU_SOURCE at all ? What is the argument of
not exposing *ALL* stuff that is in musl ?
- Is there a way to do proper feature detection ? I tried autoscan from
autotools, but the outcome wanted to make me cry. It missed about all
that is important.
Any comments / suggestions ?
Regards,
Igmar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 'Proper' software writing
2012-09-03 13:55 'Proper' software writing Igmar Palsenberg
@ 2012-09-03 14:32 ` Szabolcs Nagy
2012-09-04 1:50 ` Rich Felker
1 sibling, 0 replies; 6+ messages in thread
From: Szabolcs Nagy @ 2012-09-03 14:32 UTC (permalink / raw)
To: musl
* Igmar Palsenberg <musl@palsenberg.com> [2012-09-03 15:55:47 +0200]:
> - Why use _BSD_SOURCE and _GNU_SOURCE at all ? What is the argument of
> not exposing *ALL* stuff that is in musl ?
> - Is there a way to do proper feature detection ? I tried autoscan from
> autotools, but the outcome wanted to make me cry. It missed about all
> that is important.
>
> Any comments / suggestions ?
>
see the archive, we just had a discussion about this
here is the summary:
http://www.openwall.com/lists/musl/2012/09/03/1
currently the easy way to work around broken code is
to add -D_GNU_SOURCE to the CFLAGS
exposing all stuff by default is not what you want:
many of the symbols are obsolete/broken, there are bsd
symbols not present in glibc and simple symbols that
violate the standard namespace (so they can easily cause
problems if made visible by default)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 'Proper' software writing
2012-09-03 13:55 'Proper' software writing Igmar Palsenberg
2012-09-03 14:32 ` Szabolcs Nagy
@ 2012-09-04 1:50 ` Rich Felker
2012-09-04 9:41 ` Igmar Palsenberg
1 sibling, 1 reply; 6+ messages in thread
From: Rich Felker @ 2012-09-04 1:50 UTC (permalink / raw)
To: musl
On Mon, Sep 03, 2012 at 03:55:47PM +0200, Igmar Palsenberg wrote:
> Hi,
>
> When attempting to fix my own piece of software I've come to the
> conclusing that writing somewhat portable software (glibc vs musl) is a
> huge PITA.
Yes. Actually it's also a huge PITA between other implementations too,
but the breakage is all a lot more subtle. Basically the surest way to
write portable software is to use _POSIX_C_SOURCE or _XOPEN_SOURCE and
write purely to the standards, not using any extension functionality,
but often you want or even need at least some extensions that are
pretty much universally available, and then there's no well-defined
way to get them...
> - Why use _BSD_SOURCE and _GNU_SOURCE at all ? What is the argument of
> not exposing *ALL* stuff that is in musl ?
All is probably too much; there's a lot of ugly cruft (like lowercase
macros named major and minor getting exposed whenever you include
stdlib.h) in the "expose it all" _GNU_SOURCE profile. This is bad
enough if you're requesting it, but really bad if it's just there by
default.
I'm well aware that your frustration is the first/biggest FAQ people
have when trying to use musl and that it's a bad first experience.
Right now there's a big ongoing thread about what to do about it, and
we're doing some research on applications and the headers themselves
to figure out what a sane, clean, default profile to expose would be.
> - Is there a way to do proper feature detection ? I tried autoscan from
> autotools, but the outcome wanted to make me cry. It missed about all
> that is important.
Gregor has a really good guide to using autotools properly, and some
tricks to make generated autoconf scripts lighter/faster by
dummying-out useless ones:
https://bitbucket.org/GregorR/autoconf-lean
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 'Proper' software writing
2012-09-04 1:50 ` Rich Felker
@ 2012-09-04 9:41 ` Igmar Palsenberg
2012-09-04 11:18 ` Igmar Palsenberg
2012-09-04 13:32 ` Rich Felker
0 siblings, 2 replies; 6+ messages in thread
From: Igmar Palsenberg @ 2012-09-04 9:41 UTC (permalink / raw)
To: musl
On 9/4/12 3:50 AM, Rich Felker wrote:
> On Mon, Sep 03, 2012 at 03:55:47PM +0200, Igmar Palsenberg wrote:
>> Hi,
>>
>> When attempting to fix my own piece of software I've come to the
>> conclusing that writing somewhat portable software (glibc vs musl) is a
>> huge PITA.
> Yes. Actually it's also a huge PITA between other implementations too,
> but the breakage is all a lot more subtle. Basically the surest way to
> write portable software is to use _POSIX_C_SOURCE or _XOPEN_SOURCE and
> write purely to the standards, not using any extension functionality,
> but often you want or even need at least some extensions that are
> pretty much universally available, and then there's no well-defined
> way to get them...
This code is Linux only. I basically can use _GNU_SOURCE, but that pulls
in way to much, and not to mention
things you don't want in decent software. For now, I've settled for
_XOPEN_SOURCE and _BSD_SOURCE, and redefine the stuff I need (dladdr(),
some network related defines).
That seems to work for me. I've broken my glibc build, but that's a fix
for later :)
>> - Why use _BSD_SOURCE and _GNU_SOURCE at all ? What is the argument of
>> not exposing *ALL* stuff that is in musl ?
> All is probably too much; there's a lot of ugly cruft (like lowercase
> macros named major and minor getting exposed whenever you include
> stdlib.h) in the "expose it all" _GNU_SOURCE profile. This is bad
> enough if you're requesting it, but really bad if it's just there by
> default.
>
> I'm well aware that your frustration is the first/biggest FAQ people
> have when trying to use musl and that it's a bad first experience.
I like clean software. Musl helps with that, so that you actually
*think* before coding. Musl and -Werror are my best friends for now.
I've had more bad experiences with GNU software then with Musl. Musl I
can usually fix myself, GNU tools are usually a whole different story.
> Right now there's a big ongoing thread about what to do about it, and
> we're doing some research on applications and the headers themselves
> to figure out what a sane, clean, default profile to expose would be.
>
>> - Is there a way to do proper feature detection ? I tried autoscan from
>> autotools, but the outcome wanted to make me cry. It missed about all
>> that is important.
> Gregor has a really good guide to using autotools properly, and some
> tricks to make generated autoconf scripts lighter/faster by
> dummying-out useless ones:
>
> https://bitbucket.org/GregorR/autoconf-lean
>
Thanks. I'll look into that.
Regards,
Igmar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 'Proper' software writing
2012-09-04 9:41 ` Igmar Palsenberg
@ 2012-09-04 11:18 ` Igmar Palsenberg
2012-09-04 13:32 ` Rich Felker
1 sibling, 0 replies; 6+ messages in thread
From: Igmar Palsenberg @ 2012-09-04 11:18 UTC (permalink / raw)
To: musl
>>> - Is there a way to do proper feature detection ? I tried autoscan from
>>> autotools, but the outcome wanted to make me cry. It missed about all
>>> that is important.
>> Gregor has a really good guide to using autotools properly, and some
>> tricks to make generated autoconf scripts lighter/faster by
>> dummying-out useless ones:
>>
>> https://bitbucket.org/GregorR/autoconf-lean
>>
> Thanks. I'll look into that.
Useful. Also a reminder why usually my pants drop down within the hour :
I want autoconf, not automake : My makefiles are good. Very good if I
say so myself. install-sh (or install.sh) is installed my automake,
but I don't want automake. autoconf requires install.sh it however. WTF ?
I ended up making a copy...
Igmar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 'Proper' software writing
2012-09-04 9:41 ` Igmar Palsenberg
2012-09-04 11:18 ` Igmar Palsenberg
@ 2012-09-04 13:32 ` Rich Felker
1 sibling, 0 replies; 6+ messages in thread
From: Rich Felker @ 2012-09-04 13:32 UTC (permalink / raw)
To: musl
On Tue, Sep 04, 2012 at 11:41:18AM +0200, Igmar Palsenberg wrote:
> On 9/4/12 3:50 AM, Rich Felker wrote:
> > On Mon, Sep 03, 2012 at 03:55:47PM +0200, Igmar Palsenberg wrote:
> >> Hi,
> >>
> >> When attempting to fix my own piece of software I've come to the
> >> conclusing that writing somewhat portable software (glibc vs musl) is a
> >> huge PITA.
> > Yes. Actually it's also a huge PITA between other implementations too,
> > but the breakage is all a lot more subtle. Basically the surest way to
> > write portable software is to use _POSIX_C_SOURCE or _XOPEN_SOURCE and
> > write purely to the standards, not using any extension functionality,
> > but often you want or even need at least some extensions that are
> > pretty much universally available, and then there's no well-defined
> > way to get them...
> This code is Linux only. I basically can use _GNU_SOURCE, but that pulls
> in way to much, and not to mention
> things you don't want in decent software. For now, I've settled for
> _XOPEN_SOURCE and _BSD_SOURCE, and redefine the stuff I need (dladdr(),
> some network related defines).
If dladdr is missing with _BSD_SOURCE, I think that's a bug in our
headers. The FreeBSD man pages document it, so I think it should be
included in the _BSD_SOURCE profile. I'm holding off on making any
header changes right this moment because there's a HUGE pending patch
to add correct C99 restrict keyword usage everywhere it belongs in
musl, and changing the headers now would make extra work resolving
conflicts, but I'll fix it soon.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-09-04 13:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-03 13:55 'Proper' software writing Igmar Palsenberg
2012-09-03 14:32 ` Szabolcs Nagy
2012-09-04 1:50 ` Rich Felker
2012-09-04 9:41 ` Igmar Palsenberg
2012-09-04 11:18 ` Igmar Palsenberg
2012-09-04 13:32 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).