# Heimdal Compilation/Install Error



## dehuu76 (Jan 8, 2022)

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


----------



## SirDice (Jan 10, 2022)

Post the whole error, not just the last bit of it. And please, just copy/paste the text. Don't post pictures of text.


----------



## dehuu76 (Jan 10, 2022)

The whole compilation process takes a long time and at the end it outputs such lines.

```
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


----------



## SirDice (Jan 10, 2022)

One of the dependencies of security/heimdal fails to build for some reason. That causes the whole process to stop. Start with the first one that appears to fail; security/cyrus-sasl2-gssapi.


----------



## dehuu76 (Jan 10, 2022)

I tried to compile security/cyrus-sasl2-gssapi first. Options with_heimdal. I got the same errors


----------



## SirDice (Jan 10, 2022)

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.


----------



## T-Daemon (Jan 10, 2022)

Use script(1) to catch all the build process printed on the terminal. Paste output beginning with the lines before the first error appears.


----------



## dehuu76 (Jan 11, 2022)

Script fragment output. Freebsd13.0-stable #0

```
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
```


----------



## T-Daemon (Jan 11, 2022)

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.


----------



## dehuu76 (Jan 11, 2022)

Here is a full log


----------



## SirDice (Jan 11, 2022)

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.


----------



## astyle (Jan 11, 2022)

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.


----------



## T-Daemon (Jan 11, 2022)

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:


```
===>   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






						257004 – math/lapack build of 3.10.0 fails with "argument list too long" error
					






					bugs.freebsd.org
				




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.


----------



## dehuu76 (Jan 12, 2022)

I downloaded the fresh ports today and everything compiled and installed without errors. Freebsd13-stable (snapshot 13-n248872-2c7441c86ef )


----------



## dehuu76 (Jun 29, 2022)

I installed FreeBSD 13.1 from dvd, installed ports, and have the same problem with heimdal, openldap and etc...


----------



## T-Daemon (Jun 29, 2022)

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`).


----------



## dehuu76 (Jun 29, 2022)

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


----------



## T-Daemon (Jun 29, 2022)

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`.



```
/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
```


```
/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
```


----------



## cy@ (Jun 29, 2022)

dehuu76 said:


> 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.


----------



## astyle (Jun 29, 2022)

cy@ said:


> 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:









						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




					forums.freebsd.org


----------



## PMc (Jun 30, 2022)

cy@ said:


> 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.


----------



## astyle (Jun 30, 2022)

PMc said:


> 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.


----------



## PMc (Jun 30, 2022)

astyle said:


> 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:


```
$ 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.


----------



## astyle (Jun 30, 2022)

PMc said:


> Well, not a simple way. But a reliable way does exist:
> 
> 
> ```
> ...


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.


----------



## PMc (Jun 30, 2022)

astyle said:


> 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.)


----------



## astyle (Jun 30, 2022)

PMc said:


> 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.)


PMc , your story suggests to me that there needs to be a clean separation between _detection of circular dependencies _and _compilation errors for dependent ports_. The former shows an infinite, closed loop of dependency resolution that needs to be broken by changing the knobs somewhere.  The latter actually has a stop condition that is independent of circular dependencies.


----------



## PMc (Jun 30, 2022)

astyle said:


> PMc , your story suggests to me that there needs to be a clean separation between _detection of circular dependencies _and _compilation errors for dependent ports_. The former shows an infinite, closed loop of dependency resolution that needs to be broken by changing the knobs somewhere.  The latter actually has a stop condition that is independent of circular dependencies.


That may be the case, yes. But in the way I did approach the task, this separation did not bother me. I am doing two things:
1. look at all the desired ports, make sure their options are set as desired, and gather their dependencies. Repeat doing that recursively, and write it all into a list.
2. Take that list, create a second (in-memory) list of those ports that are already present in pkg-format, and figure out what can be built next. If prereqs are needed, install them, then build the port. On success move it from the first to the second list. When the build fails, mark it as failed. (For the next port, zfs-rollback all that is not needed, then approach anew - that's my imperative, because I want reproducible builds that do not magically decide on features dependent on what is already present on the system.)

Neither 1. nor 2. can get into an infinite loop. 1. will notice that dependencies have already been gathered (which happens always when prereqs are needed for multiple ports), and 2. will just stop when nothing can be done anymore. Then somebody has to look into the matter, and that's the case anyway.
(I think there is also s report at the end, which ports have failed to build, and which had unreachable dependencies.)


----------



## astyle (Jul 1, 2022)

PMc said:


> That may be the case, yes. But in the way I did approach the task, this separation did not bother me. I am doing two things:
> 1. look at all the desired ports, make sure their options are set as desired, and gather their dependencies. Repeat doing that recursively, and write it all into a list.
> 2. Take that list, create a second (in-memory) list of those ports that are already present in pkg-format, and figure out what can be built next. If prereqs are needed, install them, then build the port. On success move it from the first to the second list. When the build fails, mark it as failed. (For the next port, zfs-rollback all that is not needed, then approach anew - that's my imperative, because I want reproducible builds that do not magically decide on features dependent on what is already present on the system.)
> 
> ...


The issue that I'm seeing here is that `make` is not that smart. It will happily compile everything it can first, then enter the dependency loop, and keep looping, unable to get out. I'd think the loop needs to be detected BEFORE compilation starts. PMc , your item #2 seems to break the loop by running `# pkg install dependencies`, rather than compiling dependencies.  The build is not gonna fail, it will just keep looping for missing dependencies.


----------



## cy@ (Jul 4, 2022)

PMc said:


> 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.


That was my point.


----------

