clang's ld doesn't recognise "-lto_library" flag on 10.6

[mojca (Mojca Miklavec)]

See ​this failed build for example. This is clang 3.9 failing to build llvm 4.0 on Snow Leopard:

  /opt/local/bin/clang-mp-3.9 -pipe -Os -arch x86_64
  -mmacosx-version-min=10.6 -Wl,-search_paths_first
  -Wl,-headerpad_max_install_names -L/opt/local/lib
  -Wl,-headerpad_max_install_names
  CMakeFiles/cmTC_25d4d.dir/testCCompiler.c.o -o cmTC_25d4d

  ld: library not found for -lto_library

  clang: error: linker command failed with exit code 1 (use -v to see
  invocation)

Joshua suggested:

Looks like ld is interpreting -lto_library as -l with a library name of to_library. No LTO support I guess.

I didn't test clang 3.8, but clang 3.7 works on 10.6 and clang 4.0 works on 10.7.

[kencu (Ken)]

This is very weird.

I wonder if this is related to clang 3.9 defaulting to libstdc++ now, and not finding the libc++ environment on 10.6 (Marcus' changes for cxx11)...

[kencu (Ken)]

mmm. probably not that, I guess, looking at the logs. libc++ is installed on 10.6 as a dependency during the build, and the build is configured to use it.

could this be relevant:

sh: pkg-config: command not found

[mojca (Mojca Miklavec)]

It might be worth fixing, but it's definitely not the source of the problem.

[michael-o0]

Would like input as well, it makes 3.9 unusable:

$ cat main.c
#include <stdio.h>

int
main (int argc, char **argv)
{
	printf("Hello\n");
	return (0);
}

$ clang -v main.c 
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.9/bin
 "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1 -fdebug-compilation-dir /Users/m -ferror-limit 19 -fmessage-length 194 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/MT/MTiEpDjxGZOrGNo6rf-bGk+++TI/-Tmp-/main-ceb961.o -x c main.c
clang -cc1 version 3.9.1 based upon LLVM 3.9.1 default target x86_64-apple-darwin10.8.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -lto_library /opt/local/libexec/llvm-3.9/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/MT/MTiEpDjxGZOrGNo6rf-bGk+++TI/-Tmp-/main-ceb961.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.1/lib/darwin/libclang_rt.osx.a
ld: library not found for -lto_library
clang: error: linker command failed with exit code 1 (use -v to see invocation)

$ ls -al /opt/local/libexec/llvm-3.9/lib/libLTO.dylib
-rwxr-xr-x  1 root  admin  179892 Apr 19 17:07 /opt/local/libexec/llvm-3.9/lib/libLTO.dylib

$ uname -a
Darwin m.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

[kencu (Ken)]

I have a slightly older clang-3.9.0 installed on 10.6, and it works fine. I pegged it at that version a few months ago, and pegged ld64 at that time too.

It looks like the /opt/local/libexec/llvm-3.9/bin/ld phase of my build does not include an -lto_library flag, whereas yours does. I'm not certain whether that request comes in from clang-3.9, or whether it's a function of ld64 (both of which have been updated several times since Dec 2016 when I pegged them last). But at least it's a clue, I hope.

$ clang --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.9/bin


$ clang -v main.c
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.9/bin
 "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 264.3.102 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0 -fdebug-compilation-dir /Users/cunningh/Desktop/test -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-6686d8.o -x c main.c
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target x86_64-apple-darwin10.8.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-6686d8.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.osx.a

[kencu (Ken)]

again, with clang-3.9.0 and ld64, this time forcing LTO -- works.

$ clang -v -flto main.c
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.9/bin
 "/opt/local/libexec/llvm-3.9/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-llvm-bc -flto -disable-free -disable-llvm-verifier -discard-value-names -main-file-name main.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 264.3.102 -v -dwarf-column-info -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0 -fdebug-compilation-dir /Users/cunningh/Desktop/test -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-9db6ce.o -x c main.c
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target x86_64-apple-darwin10.8.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.9/bin/ld" -demangle -object_path_lto /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/cc-9ece95.o -lto_library /opt/local/libexec/llvm-3.9/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.6.0 -o a.out -lcrt1.10.6.o /var/folders/I0/I0fOotq3ErGZHYxrmmWiqU+++TI/-Tmp-/main-9db6ce.o -lSystem /opt/local/libexec/llvm-3.9/bin/../lib/clang/3.9.0/lib/darwin/libclang_rt.osx.a

$ ./a.out
Hello

$ port -v installed | grep ld64
  ld64 @2_0+universal-ld64_127-ld64_136-ld64_236-ld64_97 (active) platform='darwin 10' archs='i386 x86_64' date='2016-09-01T23:15:02-0700'
  ld64-136 @136_9+llvm39-llvm34 (active) platform='darwin 10' archs='x86_64' date='2016-12-21T10:45:57-0800'
  ld64-latest @274.1_1+llvm39+universal-llvm34 (active) platform='darwin 10' archs='i386 x86_64' date='2016-12-21T15:41:59-0800'

$ port -v installed | grep clang-3.9
  clang-3.9 @3.9.0_2+analyzer (active) platform='darwin 10' archs='x86_64' date='2016-12-21T04:54:30-0800'

[kencu (Ken)]

This commit <​https://reviews.llvm.org/D25932> would appear to explain why LTO is now automatically invoked on newer llvm versions, I think. It would appear to have become the default to invoke LTO when this commit was included in an llvm version release -- presumably after 3.9.0 and before 3.9.1 as yours invokes it automatically whereas mine does not.

So I guess the remaining question is why ld64 finds the LTO library without apparent troubles on my machine, but not on your machine...

[kencu (Ken)]

With this commit <​https://github.com/macports/macports-ports/commit/393e9ab3d71d2e79d553e1373257f80b93d7c268> Jeremy changed the default ld64 on snowleopard back to ld64-127.

I'm running ld64-136 on this snowleopard machine.

[kencu (Ken)]

I notice libLTO.dylib is linked into the /opt/local/libexec/ld64/ld like so, on my current machine...

      cmd LC_LOAD_DYLIB
      cmdsize 64
      name @executable_path/../lib/libLTO.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 3.9.0
compatibility version 1.0.0

[kencu (Ken)]

OK - looking at the source code for the two versions of ld64 <​https://opensource.apple.com/tarballs/ld64/> , the issue is that ld64-127 does not understand -lto_library whereas ld64-136 does understand it.

So it appears to be the rollback to ld64-127 on snowleopard that has caused this (together with the fact that it's now the default to invoke LTO on clang-3.9.1).

Jeremy's obviously very busy these days - but presumably he had a reason to roll back ld64 on snowleopard -- I just don't know what it is.

As part of the LibcxxOnOlderSystems instructions, ld64 is meant to be upgraded to ld64_136 on snowleopard, it appears:

sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_236
sudo port -v deactivate ld64_127

[mojca (Mojca Miklavec)]

Thanks a lot for the analysis. These are the two relevant commits:

• 393e9ab3

  ld64: Default to +ld64_127 on Snow Leopard
  

• 87e7b2fc

  ld64-136: Mark port obsolete.
  
  Users should be able to use ld64-127, ld64-236, or ld64-latest instead.
  

I initially tried

sudo port -v install -ld64_127

which failed due to defunct clang 3.9. As expected and consistent with the fact that we don't have the package for ld64-latest for 10.6 from the buildbot. Note that ld64-latest needs libc++.

Then I installed

sudo port install ld64 +ld64_236 -ld64_127

and after that clang-3.9 was working again and I was able to install ld64-latest as well.

Jeremy definitely changed the default variant because he wanted to retire the port ld64-136. Why he decided to go to ld64-127 is something I don't know. Does ld64-236 build on 10.6 out of the box without having ld64-127 installed first? If so, we should definitely make ld64-236 the default for 10.6. If not, we need some additional trickery, but we really need to fix this.

[mojca (Mojca Miklavec)]

Replying to kencu:

As part of the LibcxxOnOlderSystems instructions, ld64 is meant to be upgraded to ld64_136 on snowleopard, it appears:

sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_236
sudo port -v deactivate ld64_127

No, ld64_136 no longer exists, so this would be ld64_latest.

[kencu (Ken)]

Fresh install of macports-2.4.1 on 10.6 with stock Xcode 3.2.6. No modifications made.

Version:	3.2 (10A432)
  Location:	/Developer
  Applications:
  Xcode:	3.2 (1610)
  Interface Builder:	3.2 (732)
  Instruments:	2.0 (1095)
  Dashcode:	3.0 (328)
  SDKs:
  Mac OS X:
  10.4:	(8S2167)
  10.5:	(9J61)
  10.6:	(10A432)

sudo port -v install ld64-236 downloads a prebuilt binary and installs it, with some deps.

If you uninstall all ports then try the build again, forcing a build of ld64-236, it fails on snowleopard with this old familiar error:

$ port -v installed
No ports are installed.

$ sudo port -v build ld64-236
--->  Computing dependencies for ld64-236.............................
The following dependencies will be installed: 
 bzip2
 cctools
 clang-3.4
 clang_select
 db48
 expat
 gdbm
 gettext
 ld64
 ld64-127
 libedit
 libffi
 libiconv
 libmacho-headers
 libxml2
 llvm-3.4
 llvm_select
 ncurses
 openssl
 perl5
 perl5.24
 python27
 python2_select
 python_select
 readline
 sqlite3
 xz
 zlib
Continue? [Y/n]: Y

/opt/local/bin/clang++-mp-3.4 -Os -Os -stdlib=libstdc++ -stdlib=libstdc++ -arch x86_64 -I/opt/local/libexec/llvm-3.4/include -DLTO_SUPPORT -Isrc/abstraction -Isrc/ld -Isrc/ld/parsers -I/opt/local/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_ld64/ld64-236/work/dyld-421.2/include  -c -o src/ld/passes/branch_island.o src/ld/passes/branch_island.cpp
In file included from src/ld/parsers/opaque_section_file.cpp:26:
In file included from /usr/include/c++/4.2.1/vector:65:
/usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
In file included from src/ld/parsers/macho_dylib_file.cpp:34:
In file included from /usr/include/c++/4.2.1/vector:65:
/usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
In file included from src/ld/passes/branch_island.cpp:32:
In file included from /usr/include/c++/4.2.1/vector:65:
/usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
In file included from src/other/dyldinfo.cpp:34:
In file included from /usr/include/c++/4.2.1/vector:65:
/usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
In file included from src/ld/parsers/archive_file.cpp:32:
In file included from /usr/include/c++/4.2.1/vector:65:
/usr/include/c++/4.2.1/bits/functexcept.h:41:10: fatal error: 'bits/c++config.h' file not found
#include <bits/c++config.h>
...

which is fixed as usual by adding this bit into the Portfile in the ld64-236 section:

configure.cppflags-append -I/usr/include/c++/4.2.1/i686-apple-darwin10

and then ld64-236 builds through to completion, with a few warnings, and installs OK. In the end, here is what you're left with:

$ port -v installed | grep ld64
  ld64 @3_0+ld64_127 (active) platform='darwin 10' archs='x86_64' date='2017-04-22T11:24:34-0700'
  ld64-127 @127.2_14+llvm34 (active) platform='darwin 10' archs='x86_64' date='2017-04-22T11:24:32-0700'
  ld64-236 @236.3_7+llvm34 (active) platform='darwin 10' archs='x86_64' date='2017-04-22T12:08:21-0700'

[mojca (Mojca Miklavec)]

I don't understand the "fixed as usual" bit (I'm not familiar with this kind of a fix, but I'm not a regular user of 10.6).

But that indeed means that there is a bit of a bootstrapping problem at the moment and we would run into problems if we simply changed the default version without changing anything else (installing the binary "doesn't count").

What would be the best/proper fix?

[kencu (Ken)]

Replying to mojca:

I don't understand the "fixed as usual" bit (I'm not familiar with this kind of a fix, but I'm not a regular user of 10.6).

What I mean is that it's a bug we had worked on before in clang, a couple of times in my case, like this similar ticket you reported before 50845, and reported upstream by Jeremy ​https://bugs.llvm.org//show_bug.cgi?id=30858

But that indeed means that there is a bit of a bootstrapping problem at the moment and we would run into problems if we simply changed the default version without changing anything else (installing the binary "doesn't count").

I'm not sure why I'm seeing that bits/c++config.h issue again on this machine. I'll boot into a different MacPro I have that is also running 10.6 and build everything including all the deps from source, and see if it still happens.

What would be the best/proper fix?

[kencu (Ken)]

I tried this with a fresh 10.6 VM, with basic Xcode 3.2. I did not see the bits/c++config.h issue with this clean new system, so that must be something specific about the older 10.6 system that I will need to clean up.

First I tried changing the default ld64 to ld64-236 in the ld64 Portfile, but ld64-236 has a dependency on clang-3.4 to build, and clang-3.4 had a dependency on ld64 to build, so ld64-236 cannot be the default on 10.6.

Leaving the default ld64 as ld64-127 on 10.6, clang-3.4 will successfully build, and then you can use that to build ld64-236. ld64-236 or newer is needed to successfully run clang-3.9 with LTO support, as above.

So the simple step to enable 10.6 to run clang-3.9 is to first run sudo port -v install ld64-236, which will in fact build through to completion on an unmodified 10.6 system.

ld64-latest has an amazing amount of build deps on 10.6, including llvm/clang 3.7, 3.8, AND 3.9, and I didn't start that build process running but I see no reason why it shouldn't complete once started.

is it possible to set something like ld64-236 or newer as runtime dependency for clang-3.9?

[mojca (Mojca Miklavec)]

Replying to kencu:

First I tried changing the default ld64 to ld64-236 in the ld64 Portfile, but ld64-236 has a dependency on clang-3.4 to build, and clang-3.4 had a dependency on ld64 to build, so ld64-236 cannot be the default on 10.6.

OK, that's what I suspected.

So the simple step to enable 10.6 to run clang-3.9 is to first run sudo port -v install ld64-236, which will in fact build through to completion on an unmodified 10.6 system.

ld64-latest has an amazing amount of build deps on 10.6, including llvm/clang 3.7, 3.8, AND 3.9, and I didn't start that build process running but I see no reason why it shouldn't complete once started.

I suspect the large number of dependencies is due to trying to avoid dependency cycles.

is it possible to set something like ld64-236 or newer as runtime dependency for clang-3.9?

What I didn't test yet is whether it's enough to have ld64-236 installed or whether you actually need ld64 +ld64_236. If it's enough to just install ld64-236, I would indeed try adding that as a runtime dependency to clang 3.9. What I'm not sure about is whether it's possible to define "one or the other" as a runtime dependency in a way that won't kill us in cycles.

I feel like we need some better way to handle circular dependencies in cases when a compiler can build a newer version of itself.

[dliessi (Davide Liessi)]

Any news on this?

[jeremyhu (Jeremy Huddleston Sequoia)]

clang seems at first glance to be doing the right thing here:

  unsigned Version[5] = {0, 0, 0, 0, 0};
  if (Arg *A = Args.getLastArg(options::OPT_mlinker_version_EQ)) {
    if (!Driver::GetReleaseVersion(A->getValue(), Version))
      D.Diag(diag::err_drv_invalid_version_number) << A->getAsString(Args);
  }

   ...

  // Use -lto_library option to specify the libLTO.dylib path. Try to find
  // it in clang installed libraries. ld64 will only look at this argument
  // when it actually uses LTO, so libLTO.dylib only needs to exist at link
  // time if ld64 decides that it needs to use LTO.
  // Since this is passed unconditionally, ld64 will never look for libLTO.dylib
  // next to it. That's ok since ld64 using a libLTO.dylib not matching the
  // clang version won't work anyways.
  if (Version[0] >= 133) {
    // Search for libLTO in <InstalledDir>/../lib/libLTO.dylib
    StringRef P = llvm::sys::path::parent_path(D.Dir);
    SmallString<128> LibLTOPath(P);
    llvm::sys::path::append(LibLTOPath, "lib");
    llvm::sys::path::append(LibLTOPath, "libLTO.dylib");
    CmdArgs.push_back("-lto_library");
    CmdArgs.push_back(C.getArgs().MakeArgString(LibLTOPath));
  }

And in the -v output pasted above, I see -target-linker-version 136 being passed to clang, so the issue is that it thinks the linker is a newer version than it really is.

[jeremyhu (Jeremy Huddleston Sequoia)]

And the default for that should be set to the version of ld64 that was present at build time:

// Add a default value of -mlinker-version=, if one was given and the user
// didn't specify one.
#if defined(HOST_LINK_VERSION)
  if (!Args.hasArg(options::OPT_mlinker_version_EQ) &&
      strlen(HOST_LINK_VERSION) > 0) {
    DAL->AddJoinedArg(0, Opts->getOption(options::OPT_mlinker_version_EQ),
                      HOST_LINK_VERSION);
    DAL->getLastArg(options::OPT_mlinker_version_EQ)->claim();
  }
#endif

So this should be fixed by just revbumping the clang ports to rebuild with an updated HOST_LINK_VERSION.

[jeremyhu (Jeremy Huddleston Sequoia)]

In 2a81fb5cbbbb92eec5efa10dab4f6259ac8573e3/macports-ports:

clang-3.[89]: Revbump to ensure HOST_LINK_VERSION is correct.

Closes: #53931
Regressed-in: 393e9ab3d71d2e79d553e1373257f80b93d7c268
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>

[kencu (Ken)]

Jeremy - the revbump might work but I don't think so - but I was too verbose above.

Short short short answer is ld64-127 (the current 10.6 default ld64) doesn't understand the flag -lto-library. And clang-3.9.1 uses this by default.

I had ld64-136 installed previously (before the regression).

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to kencu:

Jeremy - the revbump might work but I don't think so - but I was too verbose above.

Short short short answer is ld64-127 (the current 10.6 default ld64) doesn't understand the flag -lto-library. And clang-3.9.1 uses this by default.

No. clang-3.9.1 uses it if the value of -mlinker-version= is >= 133, and if -mlinker-version= is not passed in explicitly, it uses the version of ld that was present at build time.

I had ld64-136 installed previously (before the regression).

Exactly. clang-3.9 was built when ld64-136 was active. When it was downgraded to 127, you hit this problem because clang assumed it had version 136.

Revbumping forces a rebuild with ld64-127 active and thus clang-3.9 won't pass it on such installs.

[kencu (Ken)]

I get it now. I should have read through comment:21 more carefully. Thanks.