Opened 2 years ago

Last modified 5 months ago

#60852 assigned defect

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

Reported by: ryandesign (Ryan Schmidt) Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: Cc: ra1nb0w, carlesfernandez (Carles Fernandez)
Port: gnuradio-next

Description

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>
         ^~~~~~~~~~

Change History (13)

comment:1 Changed 2 years ago by carlesfernandez (Carles Fernandez)

Cc: carlesfernandez added

comment:2 Changed 21 months ago by ryandesign (Ryan 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.

comment:3 Changed 21 months ago by 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..

comment:4 Changed 21 months ago by michaelld (Michael Dickens)

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

comment:5 Changed 10 months ago by 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
Last edited 10 months ago by nospam2000 (Michael Dreher) (previous) (diff)

comment:6 Changed 10 months ago by 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));
}

Last edited 10 months ago by nospam2000 (Michael Dreher) (previous) (diff)

comment:7 in reply to:  3 Changed 10 months ago by ryandesign (Ryan 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?

comment:8 Changed 10 months ago by 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 ...

comment:9 Changed 10 months ago by ra1nb0w

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

comment:10 Changed 10 months ago by 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 += ", ";
                 }
             }

Last edited 10 months ago by nospam2000 (Michael Dreher) (previous) (diff)

comment:11 Changed 9 months ago by 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.

Last edited 9 months ago by nospam2000 (Michael Dreher) (previous) (diff)

comment:12 Changed 9 months ago by 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?

comment:13 Changed 5 months ago by 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.

Note: See TracTickets for help on using tickets.