Heimdal Compilation/Install Error

I tried to install security/heimdal (Heimdal 7.7.0) from ports and encountered an error. FreeBSD12.3 and 13. Fresh ports. Here's the picture of the error. Extra options with openldap, without ipv6
How i can fix this problems?

Thank you for any help
 

Attachments

  • heimdal_error.jpg
    heimdal_error.jpg
    40.3 KB · Views: 98
Last edited by a moderator:
Post the whole error, not just the last bit of it. And please, just copy/paste the text. Don't post pictures of text.
 
The whole compilation process takes a long time and at the end it outputs such lines.
Code:
Stop.
make[7785]: stopped in /usr/ports/security/heimdal
*** Error code 1

Stop.
make[7784]: stopped in /usr/ports/security/cyrus-sasl2-gssapi
*** Error code 1

Stop.
make[7783]: stopped in /usr/ports/net/openldap24-client
*** Error code 1

I notice errors during compilation
libldap-2.4.so.2 - not found
cyrus-sasl-gssapi>0 - not found
libgssapi.so - not found
In FreeBSD 12.2 (dvd disc, stable) with original, no updated ports heimdal compiled without errors
 
I tried to compile security/cyrus-sasl2-gssapi first. Options with_heimdal. I got the same errors
 
We cannot see what's on your screen. And I can't guess the error you are getting. We're good but we're not clairvoyant. Post the actual error.
 
Script fragment output. Freebsd13.0-stable #0
Code:
root@fr13:/usr/ports/security/cyrus-sasl2-gssapi # make

===>   cyrus-sasl-gssapi-2.1.27_2 depends on package: gmake>=4.3 - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on executable: libtool - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on file: /usr/local/lib/heimdal/libgssapi.so - not found
===>   heimdal-7.7.0_1 depends on package: pkgconf>=1.3.0_1 - found
===>   heimdal-7.7.0_1 depends on file: /usr/local/bin/makeinfo - found
===>   heimdal-7.7.0_1 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>   heimdal-7.7.0_1 depends on shared library: libreadline.so.8 - found (/usr/local/lib/libreadline.so.8)
===>   heimdal-7.7.0_1 depends on shared library: libdb-5.3.so - found (/usr/local/lib/libdb-5.3.so)
===>   heimdal-7.7.0_1 depends on shared library: libsqlite3.so - found (/usr/local/lib/libsqlite3.so)
===>   heimdal-7.7.0_1 depends on shared library: libldap-2.4.so.2 - not found
===>  Staging for openldap24-client-2.4.59_4
===>   openldap24-client-2.4.59_4 depends on package: cyrus-sasl-gssapi>0 - not found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on package: gmake>=4.3 - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on executable: libtool - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on file: /usr/local/lib/heimdal/libgssapi.so - not found
===>   heimdal-7.7.0_1 depends on package: pkgconf>=1.3.0_1 - found
===>   heimdal-7.7.0_1 depends on file: /usr/local/bin/makeinfo - found
===>   heimdal-7.7.0_1 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>   heimdal-7.7.0_1 depends on shared library: libreadline.so.8 - found (/usr/local/lib/libreadline.so.8)
===>   heimdal-7.7.0_1 depends on shared library: libdb-5.3.so - found (/usr/local/lib/libdb-5.3.so)
===>   heimdal-7.7.0_1 depends on shared library: libsqlite3.so - found (/usr/local/lib/libsqlite3.so)
===>   heimdal-7.7.0_1 depends on shared library: libldap-2.4.so.2 - not found
===>  Staging for openldap24-client-2.4.59_4
===>   openldap24-client-2.4.59_4 depends on package: cyrus-sasl-gssapi>0 - not found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on package: gmake>=4.3 - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on executable: libtool - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on file: /usr/local/lib/heimdal/libgssapi.so - not found
===>   heimdal-7.7.0_1 depends on package: pkgconf>=1.3.0_1 - found
===>   heimdal-7.7.0_1 depends on file: /usr/local/bin/makeinfo - found
===>   heimdal-7.7.0_1 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>   heimdal-7.7.0_1 depends on shared library: libreadline.so.8 - found (/usr/local/lib/libreadline.so.8)
===>   heimdal-7.7.0_1 depends on shared library: libdb-5.3.so - found (/usr/local/lib/libdb-5.3.so)
===>   heimdal-7.7.0_1 depends on shared library: libsqlite3.so - found (/usr/local/lib/libsqlite3.so)
===>   heimdal-7.7.0_1 depends on shared library: libldap-2.4.so.2 - not found
===>  Staging for openldap24-client-2.4.59_4
===>   openldap24-client-2.4.59_4 depends on package: cyrus-sasl-gssapi>0 - not found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on package: gmake>=4.3 - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on executable: libtool - found
===>   cyrus-sasl-gssapi-2.1.27_2 depends on file: /usr/local/lib/heimdal/libgssapi.so - not found
 
No problem here building and installing security/cyrus-sasl2-gssapi with GSSAPI_HEIMDAL=on, and security/heimdal with IPV6=off and LDAP=on.

I have used packages to satisfy the ports build and run dependencies. See ports(7), Example 2, target "install-missing-packages". If using this method, make sure the package repository configuration is set to "latest" (assuming the ports tree is "main", not "quarterly").

From your (incomplete) paste in post #8 it's still unclear what compilation errors the build is facing. If it's only missing libraries those can be easily installed.

If there are literal errors in the build output, please post those. Also make sure the ports tree is up to date.
 
You managed to create a dependency loop with the options you enabled. I suspect you enabled LDAP and/or LMDB on security/heimdal, which pulls in OpenLDAP, which in turn depends on Heimdal, which depends on OpenLDAP, which depends on Heimdal, repeat ad infinitum.
 
Yeah, that's a pitfall in ports' # make config option that you get - if you're not careful, you get a circular dependency. The way to break that is to make note of the flags that create a circular dependency. In OP's case, Heimdal probably should not really depend on OpenLDAP. So, start by compiling security/heimdal w/o OpenLDAP.
--
I had a similar issue awhile ago, there were like 10 different ports involved in a circular dependency, that took awhile to resolve. :p
 
Actually it builds just fine.

Built, installed those two ports with the custom option specified in post #9 and their run and build dependencies from source without problems in a VM (13.0-RELEASE amd64). What's affecting the build on your system it seems it's affecting specifically yours.

On which platform is the system running?

In your transcript there is this relevant piece of output:

Code:
===>   heimdal-7.7.0_1 depends on package: pkgconf>=1.3.0_1 - found
  ===>   heimdal-7.7.0_1 depends on file: /usr/local/bin/makeinfo - found
  make[8703]: exec(/bin/sh) failed (Argument list too long)
  *** Error code 1

The only reference I found to it is


Not sure if this has a relevance, getconf ARG_MAX returns 524288 on the build system.

You could invoke the build with make -dA to get a extensive log (after make clean). Maybe there are details which points in the right direction.
 
I downloaded the fresh ports today and everything compiled and installed without errors. Freebsd13-stable (snapshot 13-n248872-2c7441c86ef )
 
I installed FreeBSD 13.1 from dvd, installed ports, and have the same problem with heimdal, openldap and etc...
 
Without error messages it's hard to tell what's wrong. Also which options have the ports enabled or disabled?

Have you fetched a fresh ports tree?

PS: Just checked on a 13.1-RELEASE VM, security/heimdal builds fine (with IPV6=off and LDAP=on).
 
I installed fresh installation freebsd 13.1 without ports. Then fetched a fresh ports tree. Absolutely the same situation. Dependency loop and so on. Errors the same
 
Apply following:

Don't configure options for /usr/ports/security/heimdal, if configured execute make rmconfig.

security/cyrus-sasl2-gssapi is a run dependency for net/openldap24-client, which is a build/run dependecy for security/heimdal LDAP=on.


Code:
/usr/ports/security/cyrus-sasl2-gssapi # make config
     ...
     GSSAPI_HEIMDAL=on: GSSAPI support via security/heimdal
     ...

/usr/ports/security/cyrus-sasl2-gssapi # make install clean

Code:
/usr/ports/net/openldap24-client # make config
     ...
     GSSAPI=on: With GSSAPI support


# cd /usr/ports/security/heimdal

/usr/ports/security/heimdal # make clean
/usr/ports/security/heimdal # make config
     ...
     IPV6=off: IPv6 protocol support
     ...
     LDAP=on: Enable OpenLDAP KDC backend support

/usr/ports/security/heimdal # make reinstall clean
 
I tried to install security/heimdal (Heimdal 7.7.0) from ports and encountered an error. FreeBSD12.3 and 13. Fresh ports. Here's the picture of the error. Extra options with openldap, without ipv6
How i can fix this problems?

Thank you for any help
This is a circular dependency. heimdal depends on \openldap24-client which in turn depends on heimdal, which depends on heimdal, and so on. Like an infinite loop. Remove LDAP from your heimdal options or remove GSSAPI from your openldap-client options.

There is no way to check for circular dependencies in ports thus it remains the builder's responsibility to be mindful of which options are selected and how they may interact with dependent ports. It is recommended that people use binary packages instead.
 
This is a circular dependency. heimdal depends on \openldap24-client which in turn depends on heimdal, which depends on heimdal, and so on. Like an infinite loop. Remove LDAP from your heimdal options or remove GSSAPI from your openldap-client options.

There is no way to check for circular dependencies in ports thus it remains the builder's responsibility to be mindful of which options are selected and how they may interact with dependent ports. It is recommended that people use binary packages instead.
that's exactly what I said in post #12 of this thread:
 
There is no way to check for circular dependencies in ports
There certainly is. Query the dependencies of the dependent ports, recurse and see that the graph loops back.
But that doesn't belong to the responsibilities of a single port's building process.
 
and see that the graph loops back
That last part is interesting... I actually got it... That's the difference between ports and packages. With packages, you can query dependencies, and see that they're not circular. But yeah, not with ports. Ports start out with same default knobs as packages, and therefore, will have the same dependencies (which won't be circular). If you set custom options with make config, there's no good way to check if a dependency is circular or not. Even if you run make config --recursive, your best bet is to pay attention and stop if you notice the recursion going back to a port you already configured earlier.
 
Ports start out with same default knobs as packages, and therefore, will have the same dependencies (which won't be circular). If you set custom options with make config, there's no good way to check if a dependency is circular or not.
Well, not a simple way. But a reliable way does exist:

Code:
$ cd /usr/ports/www/firefox
$ for i in PKG EXTRACT PATCH FETCH BUILD LIB RUN
> do
> echo ${i}_DEPENDS: `make -V ${i}_DEPENDS | sed "s/[^ :]*:\([^ :]\)/\1/g"`
> done
PKG_DEPENDS: ports-mgmt/pkg
EXTRACT_DEPENDS:
PATCH_DEPENDS:
FETCH_DEPENDS:
BUILD_DEPENDS: devel/nspr security/nss devel/icu devel/libevent print/harfbuzz graphics/graphite2 graphics/png multimedia/dav1d multimedia/libvpx databases/py-sqlite3@py38 multimedia/v4l_compat devel/autoconf213 devel/nasm devel/yasm archivers/zip devel/wasi-libcxx devel/wasi-libc devel/wasi-compiler-rt13 devel/llvm13 devel/rust-cbindgen lang/rust www/node devel/llvm13 devel/libnotify audio/jack audio/pulseaudio audio/sndio devel/gmake converters/libiconv devel/pkgconf lang/python38 devel/desktop-file-utils x11/xorgproto x11/libX11 x11/libxcb x11/libXcomposite x11/libXdamage x11/libXext x11/libXfixes x11/libXrender x11-toolkits/libXt x11/libXrandr x11/libXtst lang/perl5.32
LIB_DEPENDS: graphics/libdrm devel/libepoll-shim x11-fonts/fontconfig print/freetype2 multimedia/aom multimedia/dav1d devel/libevent devel/libffi graphics/graphite2 print/harfbuzz devel/nspr security/nss graphics/png x11/pixman multimedia/libvpx graphics/webp devel/dbus devel/dbus-glib graphics/libglvnd accessibility/atk graphics/cairo graphics/gdk-pixbuf2 devel/glib20 devel/gettext-runtime x11-toolkits/gtk30 x11-toolkits/pango graphics/jpeg-turbo
RUN_DEPENDS: devel/libpci multimedia/ffmpeg devel/desktop-file-utils x11/libX11 x11/libxcb x11/libXcomposite x11/libXdamage x11/libXext x11/libXfixes x11/libXrender x11-toolkits/libXt x11/libXrandr x11/libXtst

So here You have the dependencies, according to the current option knobs settings. Now grab the ones you want, change into their respective directories, and repeat.
I am doing this as of here. I don't know what poudriere&friends do; I had decided to write my own, and that will just build what it can, and report "Stuck" for the rest. Then there is a file with the dependency data as above, and I have to grep through that file. Suits for me.
 
Well, not a simple way. But a reliable way does exist:

Code:
$ cd /usr/ports/www/firefox
$ for i in PKG EXTRACT PATCH FETCH BUILD LIB RUN
> do
> echo ${i}_DEPENDS: `make -V ${i}_DEPENDS | sed "s/[^ :]*:\([^ :]\)/\1/g"`
> done
PKG_DEPENDS: ports-mgmt/pkg
EXTRACT_DEPENDS:
PATCH_DEPENDS:
FETCH_DEPENDS:
BUILD_DEPENDS: devel/nspr security/nss devel/icu devel/libevent print/harfbuzz graphics/graphite2 graphics/png multimedia/dav1d multimedia/libvpx databases/py-sqlite3@py38 multimedia/v4l_compat devel/autoconf213 devel/nasm devel/yasm archivers/zip devel/wasi-libcxx devel/wasi-libc devel/wasi-compiler-rt13 devel/llvm13 devel/rust-cbindgen lang/rust www/node devel/llvm13 devel/libnotify audio/jack audio/pulseaudio audio/sndio devel/gmake converters/libiconv devel/pkgconf lang/python38 devel/desktop-file-utils x11/xorgproto x11/libX11 x11/libxcb x11/libXcomposite x11/libXdamage x11/libXext x11/libXfixes x11/libXrender x11-toolkits/libXt x11/libXrandr x11/libXtst lang/perl5.32
LIB_DEPENDS: graphics/libdrm devel/libepoll-shim x11-fonts/fontconfig print/freetype2 multimedia/aom multimedia/dav1d devel/libevent devel/libffi graphics/graphite2 print/harfbuzz devel/nspr security/nss graphics/png x11/pixman multimedia/libvpx graphics/webp devel/dbus devel/dbus-glib graphics/libglvnd accessibility/atk graphics/cairo graphics/gdk-pixbuf2 devel/glib20 devel/gettext-runtime x11-toolkits/gtk30 x11-toolkits/pango graphics/jpeg-turbo
RUN_DEPENDS: devel/libpci multimedia/ffmpeg devel/desktop-file-utils x11/libX11 x11/libxcb x11/libXcomposite x11/libXdamage x11/libXext x11/libXfixes x11/libXrender x11-toolkits/libXt x11/libXrandr x11/libXtst

So here You have the dependencies, according to the current option knobs settings. Now grab the ones you want, change into their respective directories, and repeat.
I am doing this as of here. I don't know what poudriere&friends do; I had decided to write my own, and that will just build what it can, and report "Stuck" for the rest. Then there is a file with the dependency data as above, and I have to grep through that file. Suits for me.
Thanks, PMc . What I'm seeing here is that this method relies on a premade file generated by make config. I like the checking algorithm, it does seem to have conditions to end the loop (grep the file for deps already recorded. Either say 'No loop' or 'Here is your circular dependency').

I was thinking more along the lines of running that algorithm in response to the selections made when running make config... 😅 Yeah, that is extra processor cycles, but I think that would be worthwhile.
 
Thanks, PMc . What I'm seeing here is that this method relies on a premade file generated by make config. I like the checking algorithm, it does seem to have conditions to end the loop (grep the file for deps already recorded. Either say 'No loop' or 'Here is your circular dependency').
Actually, the way I have written my stuff, it invokes make config-conditional - so when a new port is requested for a target, or an existing one got additional options after a git pull,then the options box does pop up before the dependencies are collected.
And I had that "error, circular dependency" detection scripted in earlier versions, but it seems currently good enough when it just starts to build, and then says "hey, I cannot deploy, because not all ports are built; this and this and this port did not reach the point where all dependencies were completed".

(BTW: currently my source repo is not steadily available, because I have an ugly bug in the IPS; it says EAFNOSUPPORT and crashes as soon as one switches to STARTTLS on a IPv6 mail connection.)
 
Back
Top