[krb5, curl] Add new port, and add new feature curl[gssapi]

[talregev]

• Changes comply with the maintainer guide.
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

krb5 have an issue of absolute paths that I am not sure how to fix, also I didn't succeeded to compile it on windows, but this PR is a good start.

warning: There should be no absolute paths, such as the following, in an installed package:
  /home/tal/vcpkg/packages/krb5_x64-linux
  /home/tal/vcpkg/installed
  /home/tal/vcpkg/buildtrees/krb5
  /home/tal/vcpkg/downloads
Absolute paths were found in the following files:
  /home/tal/vcpkg/packages/krb5_x64-linux/tools/krb5/bin/compile_et
  /home/tal/vcpkg/packages/krb5_x64-linux/tools/krb5/bin/krb5-config
  /home/tal/vcpkg/packages/krb5_x64-linux/tools/krb5/debug/bin/compile_et
  /home/tal/vcpkg/packages/krb5_x64-linux/tools/krb5/debug/bin/krb5-config
error: Found 1 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: /home/tal/vcpkg/ports/krb5/portfile.cmake

[dg0yt]

Doesn't this override CFLAGS completely?

[talregev]

I think not, How we can verify it?

[talregev]

from build log:

/usr/bin/cc -DHAVE_CONFIG_H  -I../../include -I../.././../src/krb5-1-8a38cd677f.clean/src/include  -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE -DNDEBUG -fcommon -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Werror=uninitialized -Wno-maybe-uninitialized -Werror=pointer-arith -Werror=int-conversion -Werror=incompatible-pointer-types -Werror=discarded-qualifiers -Werror=implicit-int -Werror=declaration-after-statement -Werror-implicit-function-declaration -pthread  -c ../.././../src/krb5-1-8a38cd677f.clean/src/util/support/threads.c

[dg0yt]

So this really overrides essential flags from vcpkg, in particular -fPIC, -g/-O3.
Try

Suggested change

	CFLAGS=-fcommon
	"CFLAGS=-fcommon \$CFLAGS"

But why is the extra flag needed at all?

[talregev]

without the flag:

/usr/bin/ld: ../../lib/libkadm5srv_mit.a(server_kdb.o):/home/tal/vcpkg/buildtrees/krb5/x64-linux-dbg/lib/kadm5/srv/../../.././../src/krb5-1-8a38cd677f.clean/src/lib/kadm5/srv/server_kdb.c:18: multiple definition of `master_keyblock'; kdb5_util.o:/home/tal/vcpkg/buildtrees/krb5/x64-linux-dbg/kadmin/dbutil/../.././../src/krb5-1-8a38cd677f.clean/src/kadmin/dbutil/kdb5_util.c:109: first defined here
collect2: error: ld returned 1 exit status

[dg0yt]

I see, really old (> 10 years) C code, and gcc 10 making '-fno-common` the default.

[talregev]

So this really overrides essential flags from vcpkg, in particular -fPIC, -g/-O3. Try

Thank you for your suggestion, it help!

/usr/bin/cc -DHAVE_CONFIG_H  -I../../include -I../.././../src/krb5-1-8a38cd677f.clean/src/include -I../.././../src/krb5-1-8a38cd677f.clean/src/lib/gssapi/generic -I../.././../src/krb5-1-8a38cd677f.clean/src/lib/gssapi/krb5 -I../../lib/gssapi/generic -I../../lib/gssapi/krb5 -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -fcommon -fPIC -g -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow -Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Werror=uninitialized -Wno-maybe-uninitialized -Werror=pointer-arith -Werror=int-conversion -Werror=incompatible-pointer-types -Werror=discarded-qualifiers -Werror=implicit-int -Werror=declaration-after-statement -Werror-implicit-function-declaration -pthread  -c ../.././../src/krb5-1-8a38cd677f.clean/src/kadmin/server/auth.c

[dg0yt]

Why shouldn't it support arm? Maybe CFLAGS issue?

[talregev]

I am not sure, I didn't debug it. Also I didn't succeeded to compile on Windows.
As I see it, I can insert this port without the support of windows and arm, and others can take this port and improve it.

[talregev]

@dg0yt How I can solve the absolute path errors?

[talregev]

Temporary workaround for absolute path problem, is to delete the tools that have the absolute path.

[talregev]

@LilyWangLL
PR is ready for review.
I am not sure why osx is failing.

[LilyWangLL]

Feature curl[gssapi] passed on x64-linux.

[talregev]

@LilyWangLL Ready for review.

[talregev]

@LilyWangLL I answer all @dg0yt request. Can you review again?

[JonLiu1993]

@talregev, this PR resulted in ci pilpline REGRESSION, but the strange thing is that I cannot reproduce these problems locally. Could you please take a look?

REGRESSION: libsoup:x64-linux failed with BUILD_FAILED. If expected, add libsoup:x64-linux=fail to /mnt/vss/_work/1/s/scripts/azure-pipelines/../ci.baseline.txt.
REGRESSION: lunarg-vulkantools:x64-linux failed with BUILD_FAILED. If expected, add lunarg-vulkantools:x64-linux=fail to /mnt/vss/_work/1/s/scripts/azure-pipelines/../ci.baseline.txt.
REGRESSION: qt5-serialbus:x64-linux failed with BUILD_FAILED. If expected, add qt5-serialbus:x64-linux=fail to /mnt/vss/_work/1/s/scripts/azure-pipelines/../ci.baseline.txt.

libsoup:x64-linux:
package-x64-linux-dbg-out.log
lunarg-vulkantools:x64-linux:
install-x64-linux-dbg-out.log
qt5-serialbus:x64-linux:
package-build-x64-linux-dbg-err.log

[talregev]

I think what happened is that krb5 port is connected automatic to these ports. by find_packeges.
It not detected on my PR because I didn't change the failed ports, and ci take them by hash.

When the failed ports changed, they detected the krb5 port, and try to compile it.
But the port needed detected with pkg-config as i did in curl.

We have 4 options:

• revert this PR.
• fix krb5 port that it will detected correctly also with find_package
• fix other ports that they detect krb5 with pkg-config
• disable the automatic detection of krb5 in the other ports.

[talregev]

@dg0yt I will glad your expert opinion as well 🙏🏻

[dg0yt]

There are two problems:

1. installation order problem. Some port auto-detect the presence of krb and use it. Then the binary artifacts depend on krb binaries without declaring them.
   This must be solved downstream. Disabling krb5 support might be the easiest fix: Not a regression within the vcpkg ecosystem. But maybe a problem for users who relied on system libs being used instead.
2. usage requirements problem. I don't know if we have a CI configuration to see that the pkg-config files are okay.
   What could be done immediately (and should have been part of the PR) is to request the krb5 feature for linux in test port vcpkg-ci-curl. This would build the curl executable with krb5.
   For CMake, there is no official Find module, so there is nothing to wrap. Downstream users need to be patched to use pkg-config from cmake to pick the full set of link libraries for static linkage. And they have to pass it on in their exports.

• revert this PR.

😵 💥

• fix krb5 port that it will detected correctly also with find_package

No, krb5 has no single item to fix or wrap for CMake.

• fix other ports that they detect krb5 with pkg-config

Problem 2 solved right. But mind problem 1.

• disable the automatic detection of krb5 in the other ports.

Problem 2 eliminated. Problem 1 solved the easy way.

[dg0yt]

As a quick CI workaround, krb5 might be added as skip to ci.baseline.txt. Unfortunately, this will not reliably unblock other PRs - they would still pull fail due to the broken binary artifacts in the cache.
And it would make the modified test port fail. So that the test port modifcation would need to come after the baseline change, and revert it.