Solved GSSAPI buildworld error

[sidetone]

When building the world from source by make buildworld, the error shows:

/usr/src/lib/libgssapi/gss_accept_sec_context.c:29:10:
    fatal error: 'gsssapi/gssapi.h' file not found
#include <gssapi/gssapi.h>

1 error generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/libgssapi
*** Error code 1

Error codes repeat with stopped in /usr/src

This has to do with setting the previous build in src.conf to WITHOUT_GSSAPI , which installing the base instructions included removing libraries, then including gssapi in the next build.

svnup didn't get the needed library file. How would I get the correct library file for gssapi, to build it in the world?

I left out GSSAPI, because I thought to play with security/libressl. A few ports and packages don't work with this setting. So, now I want to reinstall gssapi in the base.

Thank you.

 

[kpa]

That might be one of the rabbit holes you can get yourself into, the buildworld part for GSSAPI apparently expects that the GSSAPI headers are found at /usr/include and doesn't look into the temporary build tree under /usr/obj like it should. I ran into something similar when I disabled dtrace and couldn't get back to a world built with dtrace without some manual hackery. I'd file a bug report if you have repeatable steps for producing the error.

 

[sidetone]

The only repeatable steps that I'm aware of is building and installing world with the setting WITHOUT_GSSAPI=yes in /etc/src/, then later on, building world, with the WITHOUT_GSSAPI setting removed.

This is over a month apart. Perhaps it's similar to what you described, but with dtrace.

 

[ShelLuser]

There are a lot of problems coming your way if you leave some parts out of the base system. Same applies to OpenSSL (WITHOUT_OPENSSL); if you try that you'll also ending up with build errors.

Problem is that src.conf(5) mentions a lot of sometimes interesting options, but it doesn't mention which ones are mandatory and which aren't. I'm assuming that there might be some kind of work around but I never took the effort to look into that and simply ended up re-enabling certain options.

 

[sidetone]

Simply, as the error says, /usr/src/lib/libgssapi/gss_accept_sec_context.c references gssapi from line 29, and FreeBSD is missing the header file, gssapi.h.

I'm wondering if all that's missing from dtrace and openssl are also their correct header files.

I removed the ftp/curl package and installed it from ports. That solved most gssapi problems.

There are a lot of problems coming your way if you leave some parts out of the base system. Same applies to OpenSSL (WITHOUT_OPENSSL); if you try that you'll also ending up with build errors.

Problem is that src.conf(5) mentions a lot of sometimes interesting options, but it doesn't mention which ones are mandatory and which aren't. I'm assuming that there might be some kind of work around but I never took the effort to look into that and simply ended up re-enabling certain options.

I don't remember if I left openssl in.

One type of application you can usually safely remove from src.conf are clear text related internet programs. Now that xdm is installed, I'm back to drm problems that began with the upgrade, so I'm forced to use Puppy Linux for applications that require a desktop.

 

[sidetone]

I fixed it...

I went into /usr/src/include/gssapi/ and ran make clean, make install clean. Then checked to see if /usr/include/gssapi/gssapi.h with a most recent timestamp appeared.

After that, I ran make clean, make install clean from /usr/src/lib/libgssapi/. I didn't get the same install error that I got from build world, or from before making the gssapi.h include file.

Compilation of programs that require GSSAPI worked.

I ran into something similar when I disabled dtrace and couldn't get back to a world built with dtrace without some manual hackery.

I wonder if something similar would work for dtrace, to run make install somewhere from /usr/src/cddl/lib/libdtrace/, then /usr/src/cddl/usr.sbin/dtrace/. It's not worth recompiling a system to find out if that would work, it's only worth trying if the system is already like that.