gnuradio-next: fatal error: 'endian.h' file not found

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/34403/steps/install-port/logs/stdio

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_gnuradio/gnuradio-next/work/gnuradio-03d92ac19a11356175533aae4ad5804a354be075/gnuradio-runtime/lib/pmt/pmt_serialize.cc:17:10: fatal error: 'endian.h' file not found
#include <endian.h>
         ^~~~~~~~~~

[ryandesign (Ryan Carsten Schmidt)]

This is still happening:

​https://build.macports.org/builders/ports-11_x86_64-builder/builds/24723/steps/install-port/logs/stdio

Please fix the port or mark it incompatible with affected OS versions so that the build system can avoid attempting to build it.

[ra1nb0w]

@michaelld should be enough to update at least to this commit ​https://github.com/gnuradio/gnuradio/commit/7a30ee7b7528f5852884ab0a8045c0375d623840

But I don't know which gnuradio's branch do you follow..

[michaelld (Michael Dickens)]

I'll give this a go & see if it works.

[nospam2000 (Michael Dreher)]

I also have this issue today with the latest available version gnuradio-next @20200419-03d92ac1_7.

Any workaround or fix?

There is an endian.h, so probably only the include search path is wrong:

• /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/machine/endian.h
• /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/i386/endian.h
• /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/arm/endian.h

[nospam2000 (Michael Dreher)]

The following test program compiles and runs:

#include <stdio.h>
#include <stdint.h>
#include <machine/endian.h>

int main(void)
{
        uint16_t a = 0x1234;
        printf("%hx\n", htons(a));
}

This is not the correct way it is just to show that the file is in the default search path.

The following one also works because it indirectly includes machine/endian.h via <sys/types.h>

#include <stdio.h>
#include <stdint.h>
/* #include <machine/endian.h> */
#include <sys/types.h>

int main(void)
{
        uint16_t a = 0x1234;
        printf("%hx\n", htons(a));
}

The documentation of 'htons' says:

BYTEORDER(3)             BSD Library Functions Manual             BYTEORDER(3)

NAME
     htonl, htons, htonll, ntohl, ntohs, ntohll -- convert values between host and network byte order

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <arpa/inet.h>

Including <arpa/inet.h> works and would be the conformant way on macOS:

#include <stdio.h>
#include <stdint.h>
#include <arpa/inet.h>

int main(void)
{
        uint16_t a = 0x1234;
        printf("%hx\n", htons(a));
}

[ryandesign (Ryan Carsten Schmidt)]

Replying to ra1nb0w:

@michaelld should be enough to update at least to this commit ​https://github.com/gnuradio/gnuradio/commit/7a30ee7b7528f5852884ab0a8045c0375d623840

Is updating the port to a newer version feasible?

[michaelld (Michael Dickens)]

Yes it's feasible. Either @ra1nb0w or I need to find/take the time to do it! I very well might have time in the new few days, taking some forced sick time / having down time ... we'll see ...

[ra1nb0w]

this should be done when we migrate to 3.10 since it requires many dependency changes

[nospam2000 (Michael Dreher)]

The following patch makes at least that one file compileable:

--- pmt_serialize.cc.orig	2022-02-22 23:53:23.000000000 +0100
+++ pmt_serialize.cc	2022-02-22 23:59:30.000000000 +0100
@@ -14,11 +14,19 @@

 #include "pmt/pmt_serial_tags.h"
 #include "pmt_int.h"
-#include <endian.h>
+/* #include <endian.h> */
+#include <arpa/inet.h>
 #include <pmt/pmt.h>
 #include <limits>
 #include <vector>

+#define htobe32(x) (htonl(x))
+#define htobe64(x) (htonll(x))
+#define htobe16(x) (htons(x))
+#define be16toh(x) (ntohs(x))
+#define be32toh(x) (ntohl(x))
+#define be64toh(x) (ntohll(x))
+
 namespace pmt {

 static pmt_t parse_pair(std::streambuf& sb);

Just until the next build error and patch:

--- tcp_connection.cc.orig	2022-02-23 00:14:50.000000000 +0100
+++ tcp_connection.cc	2022-02-23 00:45:49.000000000 +0100
@@ -45,7 +45,7 @@
     size_t len = pmt::blob_length(vector);

     // Asio async_write() requires the buffer to remain valid until the handler is called.
-    std::shared_ptr<char[]> txbuf(new char[len]);
+    std::shared_ptr<char> txbuf(new char[len]);

     size_t temp = 0;
     memcpy(txbuf.get(), pmt::uniform_vector_elements(vector, temp), len);

But seems to be endless story:

--- osx_sink.cc.orig	2022-02-23 00:57:15.000000000 +0100
+++ osx_sink.cc	2022-02-23 00:57:22.000000000 +0100
@@ -115,7 +115,7 @@
             err_str += ": ";
             for (UInt32 nn = 0; nn < all_names.size(); ++nn) {
                 err_str += all_names[nn];
-                if (nn != all_names - 1) {
+                if (nn != all_names.size() - 1) {
                     err_str += ", ";
                 }
             }

[nospam2000 (Michael Dreher)]

I now tried to compile gnuradio 3.10 from source and had a partial success.

First the additional dependencies I needed to install:

 sudo port install texlive-latex-recommended
 sudo port install texlive-latex-extra
 sudo port install boost
 sudo port install boost178
 sudo port install boost178-numpy
 sudo port install py310-pygccxml
 sudo port install spdlog
 sudo port install libiio
 sudo port install qwtplot3d
 sudo port install qwt-qt5
 sudo port install qwt61 # qwt52 will cause compile error in gnuradio; qwt61 not detected by gnuradio Cmake

And use the following build command:

CC=/usr/bin/llvm-gcc CXX=/usr/bin/llvm-g++ cmake \
-Dpybind11_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pybind11/share/cmake/pybind11 \
-DPYTHON_EXECUTABLE=/opt/local/bin/python3.10 \
-DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/3.10/Headers \
-DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/3.10/Python \
-DSPHINX_EXECUTABLE=/opt/local/bin/rst2html-3.10.py \
-DGR_PYTHON_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages \
..

The only issue for compiling I had with that is with qwt:

• qwt52 will cause a compile error in gnuradio because a Qt define is missing.
• qwt61 is not detected by gnuradio Cmake and will cause gr-qtgui to be excluded from the build.

I also created an ​issue in the gnuradio github because in my opinion the base package should be compilable on macOS out of the box and macports should only do some packaging and defining the dependent packages but not solve compile problems.

[ra1nb0w]

You can find gnuradio 3.10 in the following repository ​https://github.com/ra1nb0w/macports-ports/tree/gnuradio-3.10

We have not yet decided if it is the right time to move stable ahead since the OOM modules is not good enough.

What do you think?

[michaelld (Michael Dickens)]

revisiting this issue: It was ​fixed in GR with this commit, which is dated Apr 23, 2020 & hence is part of GR 3.9 and 3.10 releases. Thus, we need to get the GR ports updated ... which is ​part of this PR.

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld:

which is ​part of this PR.

which was closed. Meanwhile, the port has not been buildable for three years.