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.

[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.