search

CESNET / libyang

YANG data modeling language library
BSD 3-Clause "New" or "Revised" License
355 stars 284 forks source link

libyang support on QNX platform #1051

Closed apropp-molex closed 4 years ago

apropp-molex commented 4 years ago

Hi,

I'd like to port over libyang to QNX. I've run into a couple of hiccups which I've summarized below. Let me know if you want console output for any of the issues or anything else, including a pull request.

  1. <sys/syscall.h> is not a header file found within QNX. It's included in common.c and xml.c. From what I understand on Linux, this is just a bunch of SYSxxx definitions, which I don't see any of in either C file. Perhaps the easiest solution would be #ifndef \_QNXNTO_\
  2. All the QNX endian methods (e.g., htole64, le64toh, htonl etc.) are defined in <net/netbyte.h> and should be linked against -lsocket. This is instead of . printer_lyb.c, parser_lib.c, tree_schema.c and tools/re/main.c seem to be the affected files
  3. The -ldl flag is used when creating libyang.so. Removing this manually from the cmake created files allowed libyang.so to be created and didn't raise any errors. What functions are linked with this flag?
  4. In various locations, asprintf and vasprintf are used. Since these are GNU extensions, would it be possible to provide an implementation for non-GNU systems?
  5. strndup and getline, despite being POSIX functions are not in QNX. Would it be possible to provide an implementation for these as well?
michalvasko commented 4 years ago

Hi,

  1. I have removed the header. I have went through the commit history and it simply was not removed when it was no longer needed.
  2. Okay, seems fine but I need to know the macro to use. Is __QNX__ going to work? I found it here. It also mentions __QNXNTO__ but not __QNX_NTO__.
  3. libyang loads its user type and extension plugins dynamically so it needs to be used. However, maybe it is not necessary to link it explicitly on QNX?
  4. Should not be a problem.
  5. Yeah, those are simple functions.

Regards, Michal

apropp-molex commented 4 years ago

Hi Michal,

Thanks so much for your support of QNX. It's really appreciated.

  1. Either __QNX__ or __QNXNTO__ should be fine. __QNX_NTO__ was a typo on my part. As I can only test this on QNX Neutrino and not QNX 4, it might be safer to use the __QNXNTO__ macro.
  2. It appears dlopen (and presumably its friends) are in libc for QNX. See here and here if you're interested. So I think you're right in that explicit linking is not necessary on QNX.
michalvasko commented 4 years ago

Hi, so I have performed all the necessary changes, I hope. A few notes.

As for the dl library, a cmake variable is used to link it. Based on the platform, it should be set correctly meaning it should probably be empty on QNX. So no change should be required in libyang. Also, I have not added out getline implementation and instead made yangre utility (which is the only one using it) optional to build so that you can disable it. Let me know if there are any problems.

Regards, Michal

apropp-molex commented 4 years ago

Hi Michal,

Thanks again for your efforts. You're correct about the dl library. Once I used the toolchain file here that wasn't an issue. I did find two small issues. Edited comment to include issue 3.

  1. tree_schema.h still uses native endian header files. Is this still necessary given libyang now provides it's own endian functions?
  2. va_list and its corresponding macros are defined in #include <stdarg.h>. Including that in common.h would fix the issue.
  3. Found a couple more spots where strndup and/or asprintf appear. Namely, tools/lint/main.c, tools/lint/commands.c, src/user_types/user_inet_types.c and src/user_types/user_yang_types.c
michalvasko commented 4 years ago

Hi,

  1. This was another obsolete header, simply removed.
  2. Right, forgotten about that.
  3. Okay, I was trying to avoid this but could not because of this so the compatibility functions were put into a separate file, which is compiled with the tools that may need it including yangre. THat made the option build of this utility obsolete, so I removed it again.

Regards, Michal

apropp-molex commented 4 years ago

Hi Michal,

With the below two changes, I've confirmed that everything is all good! Thanks for your help along the way.

  1. ssize_t is defined in #include <sys/types.h>. Including that in compat.h prevents a compiler error about ssize_t not being defined.
  2. The compatibility and endian functions are still in common.c and common.h. This causes duplicate function definitions. Removing them should do the trick.
michalvasko commented 4 years ago

Hi, please try it now.

  1. I was including stddef.h instead, my mistake.
  2. I made a bit of a mess in my code and had to redo some changes and I forgot to remove this the second time, sorry.

Regards, Michal

apropp-molex commented 4 years ago

Hi Michal,

It works now! Thanks so much for you help and patience.