Porting issues R1B4 vs nightly

Development Third-Party
6

OK, checked a build with boost170 here (as was in the recipe), no errors …

7

But on nightly builds it doesn’t work, for example that’s tested on hrev57267

8

OK, got the same error on nightly, strange that it works on the Beta but not on the nightly, the package is the same …

EDIT: checked with a few other recipes on nightly (64bit), those are still fine … so I’m in the dark why “this” one is failing atm …

2 Likes
9

Thanks @humdinger :slight_smile: Still not sure if this is somehow to do with something that changed in Haiku itself?

10

Those are behind _DEFAULT_SOURCE now.

11

I think (?) this should be handled in: https://github.com/haikuports/haikuports/blob/be16ca26833ac0180691621f054fe6fa68c96923/dev-libs/boost/patches/boost1.83-1.83.0.patchset#L257C8-L257C62

But seeing this hasn’t hit the beta I guess it didn’t, from the looks of it the binary “b2” is using those flags, not sure now for the rest of the source :confused:

12

Maybe for building boost itself, but the problem is in building something else that uses boost’s headers. So unless that script changes the headers for the devel package, i2pd has to define _DEFAULT_SOURCE.

3 Likes
13

Confirmed, that fixes the boost asio problem, other errors (endian related I presume) further on then, thanks @madmax !

2 Likes
14

@humdinger Maybe this topic should be renamed? As it looks it isn’t really a boost issue rather then a R1B4 vs nightly issue?

15

“Building Boost shows beta4/nightly incompatibility” ?
Or can it be more specific?

16

This could work, but it’s not just boost, recent changes for arc4random_buf() (amongst others) are infected also? So maybe something like “Porting issues R1B4 vs nightly”?

1 Like
17

Probably that header should include <features.h> which will automatically define _DEFAULT_SOURCE in most cases.

2 Likes
18

Speaking of <features.h>… I was going back and forth with @korli regarding the use of _GNU_SOURCE vs __USE_GNU over this TraX PR.

Should that file contain a guarded define for __USE_GNU? [1], or we should have a headers/compatibility/gnu/features.h one or something like that?

[1] For reference, the one from src/system/libroot/posix/glibc/include/features.h does so.

19

I have replied on github, I think we should instead remove use of __USE_GNU in our public headers (that is, in fact, only regex.h, which was copied from glibc) and make them use our version of features.h, that is not compatible with the glibc one.

In Haiku, the “internal” define is directly _GNU_SOURCE and I don’t think we should replicate the complexity of glibc features.h.

2 Likes
20

It used to be in more, but I removed some usages recently.

Isn’t it _DEFAULT_SOURCE? features.h defines that based on whether _GNU_SOURCE or others are defined.

But we still have a bunch of headers that check for _GNU_SOURCE not _DEFAULT_SOURCE. Should we fix these?

21

The way I understand the constants:

  • _DEFAULT_SOURCE is “what’s enabled by default” (unless you ask for a strict C standard). In our case this enables both GNU and BSD extensions
  • _GNU_SOURCE is “enable GNU extensions”
  • _BSD_SOURCE is “enable BSD extensions”

But… GNU does not do that. They removed _GNU_SOURCE and they have only _DEFAULT_SOURCE now, so it’s not possible to ask for GNU extensions and not BSD ones. Which means GNU extensions includes BSD extensions, and the distinction between _GNU_SOURCE and _DEFAULT_SOURCE is nonexistant now.

So, we can do like them, have only _DEFAULT_SOURCE and _BSD_SOURCE (for people who want only the BSD extensions but not the GNU ones), I guess? But there’s an argument for _DEFAULT_SOURCE also including some Haiku-specific things? Do we want to do that? Or will we make all Haiku specific things be in separate headers with different names?

22

Right now features.h doesn’t define _GNU_SOURCE automatically. So I think either it should, or instead the headers that look for it should use _DEFAULT_SOURCE, right?

Then again, GNU extensions aren’t used as commonly, so maybe things should stay more as they are.

23

Yes, in the current situation it should all use _DEFAULT_SOURCE and not _GNU_SOURCE (following what is done in glibc).

24

Maybe not a real issue beta vs nightly, but 32bit buildmaster still seems to pull in old rust version that is linked to a non existing old openssl version.

1 Like
25

Guess I hit another one checking and failing to find: -- Looking for _GNU_SOURCE - not found
In the CMakeLists.txt is:

# check if _GNU_SOURCE is available

if (NOT _GNU_SOURCE)
    check_symbol_exists(__GNU_LIBRARY__ "features.h" _GNU_SOURCE)

    if (NOT _GNU_SOURCE)
        unset(_GNU_SOURCE CACHE)
        check_symbol_exists(_GNU_SOURCE "features.h" _GNU_SOURCE)
    endif ()
endif ()