Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenBSD: "error: unknown type name 'u_int'" when compiling #20

Open
vl-ms opened this issue Oct 2, 2022 · 20 comments
Open

OpenBSD: "error: unknown type name 'u_int'" when compiling #20

vl-ms opened this issue Oct 2, 2022 · 20 comments
Labels
help wanted Extra attention is needed openbsd OpenBSD-specific issue

Comments

@vl-ms
Copy link

vl-ms commented Oct 2, 2022

Everything up until the make command worked fine. I installed required dependencies, and the configuation did not produce any errors.

$ make
Making all in src
  CC       rastertocapt.o
In file included from rastertocapt.c:30:
In file included from /usr/local/include/cups/raster.h:20:
In file included from /usr/local/include/cups/cups.h:28:
In file included from /usr/local/include/cups/ipp.h:18:
In file included from /usr/local/include/cups/http.h:39:
/usr/include/netinet/ip.h:49:2: error: unknown type name 'u_int'
        u_int     ip_hl:4,              /* header length */
        ^
/usr/include/netinet/ip.h:174:2: error: unknown type name 'u_int'
        u_int    ipt_flg:4,             /* flags, see below */
        ^
2 errors generated.
*** Error 1 in src (Makefile:401 'rastertocapt.o': @echo "  CC      " rastertocapt.o;depbase=`echo rastertocapt.o | sed 's|[^/]*$|.deps/&|;s...)
*** Error 1 in /home/unix/soft/captdriver (Makefile:435 'all-recursive': @fail=;  if (target_option=k; case ${target_option-} in  ?) ;;  *) ...)
@ghost
Copy link

ghost commented Oct 8, 2022

@vl-ms Have you tried to use gmake? OpenBSD doesn't use GNU make in their base operating system.

@vl-ms
Copy link
Author

vl-ms commented Oct 8, 2022

Yeah, forgot to mention. Gives pretty much the same error

$ gmake
Making all in src
gmake[1]: Entering directory '/home/unix/soft/captdriver/src'
  CC       rastertocapt.o
In file included from rastertocapt.c:30:
In file included from /usr/local/include/cups/raster.h:20:
In file included from /usr/local/include/cups/cups.h:28:
In file included from /usr/local/include/cups/ipp.h:18:
In file included from /usr/local/include/cups/http.h:39:
/usr/include/netinet/ip.h:49:2: error: unknown type name 'u_int'
        u_int     ip_hl:4,              /* header length */
        ^
/usr/include/netinet/ip.h:174:2: error: unknown type name 'u_int'
        u_int    ipt_flg:4,             /* flags, see below */
        ^
2 errors generated.
gmake[1]: *** [Makefile:399: rastertocapt.o] Error 1
gmake[1]: Leaving directory '/home/unix/soft/captdriver/src'
gmake: *** [Makefile:410: all-recursive] Error 1

@mounaiban
Copy link
Owner

mounaiban commented Oct 10, 2022

I'm trying to get up to speed on OpenBSD as I am writing this, but for now there's this trick from an early-2013 LinuxQuestions thread: what include am i missing for types like u_int8_t?

Maybe try adding this one line to std.h, on line 27?

#include <sys/types.h>

I'm under the impression that on Linux the typical C/C++ toolchain makes subtle but important assumptions that OpenBSD doesn't.

I also added that line #define _POSIX_C_SOURCE 199309L, in order to use POSIX signals, maybe try removing that when you compile and see if it makes a difference for you if including types.h fails.

@mounaiban mounaiban changed the title Attempting to build on OpenBSD results in a weird error OpenBSD: "error: unknown type name 'u_int'" when compiling Oct 12, 2022
@mounaiban mounaiban added help wanted Extra attention is needed openbsd OpenBSD-specific issue labels Oct 12, 2022
@vl-ms
Copy link
Author

vl-ms commented Oct 15, 2022

Adding #include <sys/types.h> did not make a difference.
After removing #define _POSIX_C_SOURCE 199309L the error changed:

make       
Making all in src
  CC       rastertocapt.o
  CC       capt-command.o
  CC       capt-status.o
  CC       generic-ops.o
  CC       printer.o
  CC       paper.o
  CC       hiscoa-common.o
  CC       hiscoa-compress.o
  CC       prn_lbp2900.o
  CCLD     rastertocapt
ld: error: unable to find library -lcups
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error 1 in src (Makefile:374 'rastertocapt': @echo "  CCLD    " rastertocapt;cc -std=c99 -Wall -Wextra -pedantic -I/usr/local/include -g...)
*** Error 1 in /home/unix/soft/captdriver (Makefile:435 'all-recursive': @fail=;  if (target_option=k; case ${target_option-} in  ?) ;;  *) ...)

@mounaiban
Copy link
Owner

@vl-ms are you compiling CUPS from source along with captdriver? Are there OpenBSD equivalents to the -dev packages on Linux?

(Sorry for the late reply, I'm still trying to figure out OpenBSD)

@ghost
Copy link

ghost commented Oct 23, 2022

@vl-ms Can you provide guide steps how install dependencies and build it in OpenBSD? I think it may help @mounaiban check why it isn't compile in OpenBSD. I would love to see captdriver work in OpenBSD too since I have lbp2900 printer at home.

@vl-ms
Copy link
Author

vl-ms commented Oct 23, 2022

@mounaiban no, we don't have -dev packages on OpenBSD. Everything is bundled in one package, sometimes the -debug packages are also made available. On installing dependencies: it's very easy, for searching the repositories we use pkg_info -Q and for installing doas pkg_add, if you're on a snapshot you should also add -D snap. In my case, I did pkg_add -D snap cups metaauto autoconf automake git. When in doubt, check the man pages or the OpenBSD FAQ, it's very good. Ah, don't forget to set up your /etc/doas.conf, I prefer to do permit persist 'your user' as root

@vl-ms
Copy link
Author

vl-ms commented Oct 23, 2022

on building, I just followed the build steps from here and added
export AUTOMAKE_VERSION=1.16 AUTOCONF_VERSION=2.71 because aclocal complained about that. Of course, if you choose to install a different version of automake & autoconf you need to edit the variables accordingly

@vl-ms
Copy link
Author

vl-ms commented Nov 19, 2022

If a problem is with getting OpenBSD to install on your devices, I recommend virt-manager or virtualbox. Both allow USB passthrough, and both should work ok with OpenBSD as a guest OS.

@mounaiban
Copy link
Owner

mounaiban commented Dec 4, 2022

@vl-ms OpenBSD was actually pretty easy to get up and running in QEMU and VirtualBox due to excellent VMM support, my sticking point is with coming to terms with differences between BSD and Linux when it comes to compiling code.

I'll get back to this when I get the time. BSD support is part of our master plan!

Hopefully no editing of makefile or automake files would be necessary. The automake documentation really makes it look like automake is too complex to document in an understandable way...

@vl-ms
Copy link
Author

vl-ms commented Dec 4, 2022

Yeah, automake certainly seems to be overcomplicated. I'm in no hurry to make this printer work tomorrow or anything, it would just be nice to be able to print something once in a while. Maybe I will contribute myself one day when I come to understand C. If you are interested in other makefile generators, I heard mostly good things about Premake (Lua + C), and heard both good and bad things about Cmake (C++). Other than that, Meson requires Python, and everything else is much more obscure. E.g. Zig is still unstable, Gradle is mostly for Android, mk requires plan9port or Go... I heard that it is a possible to write Makefiles that work with both GNU and BSD make, but I don't know of any specific guidelines which show how to do that.

@saper
Copy link

saper commented Dec 25, 2022

Maybe it helps:

I was able to successfully build and run this on FreeBSD by applying #25 and using env LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include ./configure and then gmake (GNU make). BSD make also works but re-runs all autoconf stuff and configure.

By the way, as of commit 6271924 my LBP3010 works! (it didn't work with 195ea02 due to some unexpected USB responses). Thank you very very much!

@saper
Copy link

saper commented Dec 25, 2022

#26 fixes the need to play with LDFLAGS on the command line. Just autoreconf -i and ./configure... FreeBSD make(1) also works fine.

@mounaiban
Copy link
Owner

Happy Lunar New Year, folks! You might have gotten something fortunate today... 🧧 🐇

@vl-ms @hopingstar1806 I have successfully compiled and built Captdriver in OpenBSD, with the patches in #28 by @saper. I used automake 1.16 and autoconf 2.71. Remember to git checkout the 0.1.4.2-GxB branch...!

Please let me know if it compiles and prints for you. I will be attempting some actual single and multi-page print jobs soon.

If #28 works for all of us, I'll submit a PR to Alexey's original master branch and merge it into my master branch too, making Captdriver officially BSD-compatible.

Meanwhile, I am liking OpenBSD, and take this from a Linux and macOS user. There's a considerably more reading and extra work involved (if the installer isn't already an indication), but I nothing I can't handle. I might eventually adopt it as my server OS at this rate.

P.S: My OpenBSD build environment and Captdriver build process

After completing the OpenBSD installation and setting up /etc/doas.conf run:

pkg_add cups autoconf automake git
export AUTOCONF_VERSION=2.71 AUTOMAKE_VERSION=1.16
aclocal
autoconf
automake --add-missing
./configure
make
doas make install

Also try the EXPERT VERSION for a more copy-paste-friendly experience:

pkg_add cups autoconf automake git
export AUTOCONF_VERSION=$(pkg_info -a | grep autoconf | tail -n1 | awk -F '-' '{ print $2 }' | awk -F '.' '{ print $1"."$2 }')
export AUTOMAKE_VERSION=$(pkg_info -a | grep automake | tail -n1 | awk -F '-' '{ print $2 }' | awk -F '.' '{ print $1"."$2 }')
aclocal
autoconf
automake --add-missing
./configure
make
doas make install

@saper
Copy link

saper commented Jan 23, 2023

Happy to hear it worked for you!

I think instead of

aclocal
autoconf
automake --add-missing

you can always use (in relatively modern autotools versions) this instead:

autoreconf -i

Maybe we should put this in the git building instructions as well

@mounaiban
Copy link
Owner

@saper I finally got the chance to install the driver and attempt to print pages on OpenBSD, but I ran into difficulties with CUPS' USB backend. It appears that nothing had been sent and received from the printer at all. I am suspecting that I have missed a crucial security-related step given how OpenBSD seems to be trying to get away with the minimum number of features enabled, for security purposes.

The CUPS error_log had entries like:

[Job 69] Unable to send data to printer
[Job 69] CAPT: bad reply from printer, expected A1 A1 xx xx xx xx got
[Job 69] Backend returned status 1 (failed)

The second line ends after the word 'got', as the backend did not receive anything.

I'm just going to try FreeBSD first. Isn't FreeBSD more ready to use out of the box than the other libre BSDs?

@saper
Copy link

saper commented Jan 26, 2023

It worked for me, but maybe it makes no point to switch operating systems like crazy just for this. Maybe there is some permission problem regarding reading/writing raw USB devices? You can use usbdevs(8) to find out if the device is visible at all.

On FreeBSD, one might need to adjust rights in /dev/usb/* directories, mine are set like this:

# find /dev/usb/ -name '7.7.*' -ls
   237        0 crw-rw----    1 root        cups       0xed 26 sty 21:12 /dev/usb/7.7.0
   239        0 crw-rw----    1 root        cups       0xef 26 sty 21:12 /dev/usb/7.7.1
   240        0 crw-rw----    1 root        cups       0xf0 26 sty 21:12 /dev/usb/7.7.2

ugen.4 suggests that OpenBSD is using /dev/ugenX.YY paths.

FreeBSD has this symlink there:

# find /dev/ugen7.7 -ls
   238        0 lrw-rw----    1 root         cups             9 26 sty 21:12 /dev/ugen7.7 -> usb/7.7.0

I have achieved this with the following devfs rule:

> tail -5 /etc/devfs.rules 
[localrules=10]
        add path 'ugen*' mode 0660 group cups
        add path 'usb/*'  mode 0660 group cups
        add path 'usb' mode 0770 group cups
        add path 'ulpt*' mode 0660 group cups

(as far as I know OpenBSD does not have equivalent to this, you might just need to use chmod and/or chgrp)

@mounaiban
Copy link
Owner

@saper thanks for the tip on OpenBSD's /dev/ugen* files. As expected every one of them was mode 600 or crw------. The LBP3000 was assigned the /dev/usb/ulpt0, (with mode 600 of course) according to usbdevs -vv.
Changing these files to mode 666 did not work though, so the quest continues...

Not leaving OpenBSD just yet, but I'm right now trying to find out how many of the BSDs I can print from so that I can update the Installation Guide to add something I have personally verified to work, hopefully soon so that we can get more people on board. I'm just expecting to take a while before I finally get OpenBSD to print.

@saper
Copy link

saper commented Feb 2, 2023

@vl-ms @hopingstar1806 is there any way someone can help @mounaiban to get this running? I can't seem to be able to find any reasonable docs regarding "accessing raw USB devices with OpenBSD".

@vl-ms
Copy link
Author

vl-ms commented Feb 3, 2023

I guess the best place to start is to read the USB manpage and go from there. Maybe looking at the sources of drivers for different USB devices is a good idea too: https://cvsweb.openbsd.org/src/sys/dev/usb/ I will test whether the current driver works for me on the weekends, thank you so much for the work you do!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed openbsd OpenBSD-specific issue
Projects
None yet
Development

No branches or pull requests

3 participants