Opened 4 years ago
Last modified 15 months ago
#60852 assigned defect
gnuradio-next: fatal error: 'endian.h' file not found
Reported by: | ryandesign (Ryan Carsten 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
/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 (14)
comment:1 Changed 4 years ago by carlesfernandez (Carles Fernandez)
Cc: | carlesfernandez added |
---|
comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 follow-up: 7 Changed 4 years 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:5 Changed 3 years 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?
comment:6 Changed 3 years 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)); }
comment:7 Changed 3 years ago by 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?
comment:8 Changed 3 years 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 3 years ago by ra1nb0w
this should be done when we migrate to 3.10 since it requires many dependency changes
comment:10 Changed 3 years 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 += ", "; } }
comment:11 Changed 3 years 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.
comment:12 Changed 3 years 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 follow-up: 14 Changed 2 years 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.
comment:14 Changed 15 months ago by 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.
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.