Re: [dev] [PATCH][blind] alloca #include for BSDs

[fao_]

On 2018-01-29 5:34 pm, Yuri wrote:
See sbase and blind error logs when built with -D_XOPEN_SOURCE=700 
below.


Yuri

---sbase errors---

flock.c:21:38: error: use of undeclared identifier 'LOCK_EX'
    int fd, status, savederrno, flags = LOCK_EX, nonblk = 0, oflag 
= 0;

    ^
flock.c:26:12: error: use of undeclared identifier 'LOCK_NB'
    nonblk = LOCK_NB;
 ^
flock.c:32:11: error: use of undeclared identifier 'LOCK_SH'
    flags = LOCK_SH;
    ^
flock.c:35:11: error: use of undeclared identifier 'LOCK_UN'
    flags = LOCK_UN;
    ^
flock.c:38:11: error: use of undeclared identifier 'LOCK_EX'
    flags = LOCK_EX;
    ^
flock.c:50:6: warning: implicit declaration of function 'flock' is
invalid in C99 [-Wimplicit-function-declaration]
    if (flock(fd, flags | nonblk)) {
    ^


Yes, `flock` is not part of POSIX[0]. However, I'm confused why exactly 
FreeBSD
is having a problem with this, because as you can see from the FreeBSD 
manual[1],
it's fully supported in FreeBSD with the inclusion of , 
which is
indeed present. Maybe -D_BSD_SOURCE requires a specific version 
provided, or
the definition order matters? Unfortunately I do not have a FreeBSD 
system to

check this.

[0]:http://pubs.opengroup.org/cgi/kman4.cgi?value=flock
[1]:https://www.unix.com/man-page/FreeBSD/2/flock/


[...]
---blind errors---

src/stream.c:367:73: error: use of undeclared identifier 
'MAP_ANONYMOUS'

    image = mmap(0, 2 * lframe_size + lframe_size, PROT_READ |
PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);
^


The same is true here, see both:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
https://www.unix.com/man-page/FreeBSD/2/mmap/

and note the lack / inclusion of support for MAP_ANONYMOUS respectively.

I'm sorry I cannot be of much more help. Good luck with this problem.

--
- fao_
PGP fingerprint: 739B 6C5C 3DE1 33FA
"Too enough is always not much!"

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Yuri]

On 01/29/18 02:05, Nick wrote:

I believe the reason suckless projects stick to = rather than += or
?= is that they aren't POSIX / OSI standard.


Please also note that blind fails with FreeBSD make (PMake):

> ===>  Building for blind-1.1
> make[1]: make[1]: don't know how to make blind-arithm. Stop

It succeeds with gmake.

PMake is supposed to be closer to POSIX.


Yuri

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Yuri]

On 01/28/18 19:47, fao_ wrote:


-D_XOPEN_SOURCE=700 is equal to #include _XOPEN_SOURCE 700

It states that the compiler should use POSIX 2008 with XSI extensions.
FreeBSD supports POSIX 2008 as far as I can tell, so this is probably 
a bug with their implementation.
Could you please post the error that occured? 



See sbase and blind error logs when built with -D_XOPEN_SOURCE=700 below.


Yuri


---sbase errors---

flock.c:21:38: error: use of undeclared identifier 'LOCK_EX'
    int fd, status, savederrno, flags = LOCK_EX, nonblk = 0, oflag = 0;
    ^
flock.c:26:12: error: use of undeclared identifier 'LOCK_NB'
    nonblk = LOCK_NB;
 ^
flock.c:32:11: error: use of undeclared identifier 'LOCK_SH'
    flags = LOCK_SH;
    ^
flock.c:35:11: error: use of undeclared identifier 'LOCK_UN'
    flags = LOCK_UN;
    ^
flock.c:38:11: error: use of undeclared identifier 'LOCK_EX'
    flags = LOCK_EX;
    ^
flock.c:50:6: warning: implicit declaration of function 'flock' is 
invalid in C99 [-Wimplicit-function-declaration]

    if (flock(fd, flags | nonblk)) {
    ^
join.c:323:13: warning: variable 'fileno' is used uninitialized whenever 
'if' condition is false [-Wsometimes-uninitialized]

    } else if ((s[0] == '1' || s[0] == '2') && s[1] == '.') {
   ^~~
join.c:331:15: note: uninitialized use occurs here
    sp->fileno = fileno;
 ^~
join.c:323:9: note: remove the 'if' if its condition is always true
    } else if ((s[0] == '1' || s[0] == '2') && s[1] == '.') {
   ^

---blind errors---

src/stream.c:367:73: error: use of undeclared identifier 'MAP_ANONYMOUS'
    image = mmap(0, 2 * lframe_size + lframe_size, PROT_READ | 
PROT_WRITE, MAP_ANONYMOUS | MAP_SHARED, -1, 0);

^

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Nick]

Quoth Anthony J. Bentley:
> Variables set with = can easily be overridden by packagers simply by
> passing them as arguments to make(1).
> 
> That's fine for warnings and optimization flags since changing them
> doesn't hurt anything. If -std=c99 is necessary for the build, it
> shouldn't be in CFLAGS at all for that reason.

I see the logic, however to my knowledge no distributor has ever 
complained about the build process for dwm, which uses the same 
system, and is very widely distributed. So I'd be inclined to keep 
it as is until such a time as someone comes up with a real use-case 
for changing it. 

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Mattias Andrée]

On Mon, 29 Jan 2018 10:05:51 +
Nick  wrote:

> Quoth Yuri: 
> > You should also change your config.mk files to allow external optimization
> > and other flags. For example:
> >   
> > > CFLAGS   = -std=c99 -Wall -pedantic -O2  
> > 
> > should be changed to
> >   
> > > CFLAGS   ?= -O2  
> >   
> > > CFLAGS   += -std=c99 -Wall -pedantic -O2  
> > 
> > This way you can allow externally supplied optimization flags while still
> > being able to add your own flags. Same with CPPFLAGS and LDFLAGS.  
> 
> I believe the reason suckless projects stick to = rather than += or 
> ?= is that they aren't POSIX / OSI standard. I don't think there's a 
> compelling reason to switch to your syntax, as distribution builders 
> or whoever can still easily see what the CFLAGS were and add to them 
> if they want or need to.
> 
> Nick
> 

Indeed POSIX only defines =. An alternative would be to do

_CFLAGS = -std=c99 -Wall -pedantic -O2 $(CFLAGS)

but I think it is preferable if the package maintainer just
take the values found in config.mk, made necessary changes
(such as add flags for specific OSes), add the package
managers flags, and invoke make(1) with those values. However,
if the package maintainer is comfortable with assuming make(1)
supports ?= and +=, use sed(1) on config.mk, and he will not
have to change if config.mk has changed when a new version is
published.


Mattias Andrée


pgpauSci7jrCw.pgp
Description: OpenPGP digital signature

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Anthony J. Bentley]

Nick writes:
> Quoth Yuri: 
> > You should also change your config.mk files to allow external optimization
> > and other flags. For example:
> > 
> > > CFLAGS   = -std=c99 -Wall -pedantic -O2
> > 
> > should be changed to
> > 
> > > CFLAGS   ?= -O2
> > 
> > > CFLAGS   += -std=c99 -Wall -pedantic -O2
> > 
> > This way you can allow externally supplied optimization flags while still
> > being able to add your own flags. Same with CPPFLAGS and LDFLAGS.
>
> I believe the reason suckless projects stick to = rather than += or 
> ?= is that they aren't POSIX / OSI standard. I don't think there's a 
> compelling reason to switch to your syntax, as distribution builders 
> or whoever can still easily see what the CFLAGS were and add to them 
> if they want or need to.

Variables set with = can easily be overridden by packagers simply by
passing them as arguments to make(1).

That's fine for warnings and optimization flags since changing them
doesn't hurt anything. If -std=c99 is necessary for the build, it
shouldn't be in CFLAGS at all for that reason.

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Nick]

Quoth Yuri: 
> You should also change your config.mk files to allow external optimization
> and other flags. For example:
> 
> > CFLAGS   = -std=c99 -Wall -pedantic -O2
> 
> should be changed to
> 
> > CFLAGS   ?= -O2
> 
> > CFLAGS   += -std=c99 -Wall -pedantic -O2
> 
> This way you can allow externally supplied optimization flags while still
> being able to add your own flags. Same with CPPFLAGS and LDFLAGS.

I believe the reason suckless projects stick to = rather than += or 
?= is that they aren't POSIX / OSI standard. I don't think there's a 
compelling reason to switch to your syntax, as distribution builders 
or whoever can still easily see what the CFLAGS were and add to them 
if they want or need to.

Nick

Re: [dev] [PATCH][blind] alloca #include for BSDs

[fao_]

On 2018-01-28 10:18 pm, Yuri wrote:

Additionally, -D_XOPEN_SOURCE=700 causes build failures on FreeBSD. I
had to patch it away in both cases. Not sure what it is and why it is
there, just reporting this problem.


-D_XOPEN_SOURCE=700 is equal to #include _XOPEN_SOURCE 700

It states that the compiler should use POSIX 2008 with XSI extensions.
FreeBSD supports POSIX 2008 as far as I can tell, so this is probably a 
bug with their implementation.

Could you please post the error that occured?

--
- fao_
PGP fingerprint: 739B 6C5C 3DE1 33FA
"Too enough is always not much!"

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Yuri]

On 01/28/18 13:29, Mattias Andrée wrote:

Thanks again!

I will be fixing this, but probably via config.mk.



You're welcome!



Few more things:


You should also change your config.mk files to allow external 
optimization and other flags. For example:


> CFLAGS   = -std=c99 -Wall -pedantic -O2

should be changed to

> CFLAGS   ?= -O2

> CFLAGS   += -std=c99 -Wall -pedantic -O2

This way you can allow externally supplied optimization flags while 
still being able to add your own flags. Same with CPPFLAGS and LDFLAGS.


I looked at blind and sbase projects, this applies to both.


Additionally, -D_XOPEN_SOURCE=700 causes build failures on FreeBSD. I 
had to patch it away in both cases. Not sure what it is and why it is 
there, just reporting this problem.



Cheers!
Yuri

Re: [dev] [PATCH][blind] alloca #include for BSDs

[Mattias Andrée]

On Sun, 28 Jan 2018 13:24:06 -0800
Yuri  wrote:

> BSDs use different header for alloca than Linux.
> 
> It sucks when it only works on Linux.
> 
> 
> Thanks,
> 
> Yuri
> 
> 
> 
> --- src/blind-split.c.orig  2017-05-06 11:27:39 UTC
> +++ src/blind-split.c
> @@ -2,7 +2,11 @@
>   #include "stream.h"
>   #include "util.h"
> 
> +#if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) 
> || defined(__DragonFly__)
> +#include 
> +#else
>   #include 
> +#endif
>   #include 
>   #include 
>   #include 
> 
> 

Thanks again!

I will be fixing this, but probably via config.mk.


Mattias Andrée