# After update to 12: Unable to determine linker type from LD=ld



## goshanecr (Nov 23, 2018)

Good day!

I'm update system from 11.1 to 12.0-PRERELEASE and after

```
make buildworld
make kernel
reboot
single user: mergemaster -p
single user: make installworld
reboot
```

When after installing world I'm do:

```
mergemaster -F
```
I have error:

```
Bad system call
make[2]: "/usr/src/share/mk/bsd.linker.mk" line 52: warning: Unable to determine linker type from LD=ld
make[2]: "/usr/src/share/mk/bsd.linker.mk" line 65: warning: Unknown linker from LD=ld: none, defaulting to bfd
Bad system call

  *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
      the temproot environment
```

What's wrong?


----------



## yuripv (Nov 23, 2018)

Apparently, "Bad system call" is what's really wrong here.  Are you sure the kernel was built/installed successfully? `uname -v`?


----------



## goshanecr (Nov 23, 2018)

Kernel installed successfull, errors I don't see

```
FreeBSD 12.0-PRERELEASE r340743 BSDSERV
```
If I'm now try installkernel once again it gives me:

```
Bad system call
make[2]: "/usr/src/share/mk/bsd.linker.mk" line 52: warning: Unable to determine linker type from LD=ld
make[2]: "/usr/src/share/mk/bsd.linker.mk" line 65: warning: Unknown linker from LD=ld: none, defaulting to bfd
make[2]: "/usr/src/sys/conf/kern.pre.mk" line 127: amd64/arm64/i386 kernel requires linker ifunc support
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1
```


----------



## ShelLuser (Nov 23, 2018)

What's in your /etc/src.conf and /etc/make.conf?

Most likely you tried to 'tune' the system a bit too much and left out things which actually mattered.

(edit)

PS: Since mergemaster is a shell script that's not the source of your error message: apparently you can't start certain userland programs anymore. Ergo: this is most likely caused by a bad build.


----------



## goshanecr (Nov 23, 2018)

Yes, I have tunes in /etc/src.conf

```
WITHOUT_ACCT=YES
WITHOUT_AMD=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_ATM=YES
WITHOUT_AUDIT=YES
WITHOUT_AUTHPF=YES
# WITHOUT_BIND=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BSNMP=YES
# WITHOUT_CLANG=YES
WITHOUT_CTM=YES
WITHOUT_DEBUG_FILES=YES
WITHOUT_FDT=YES
WITHOUT_FLOPPY=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_GDB=YES
WITHOUT_HTML=YES
WITHOUT_IPFILTER=YES
WITHOUT_IPX=YES
WITHOUT_KERNEL_SYMBOLS=YES
WITHOUT_KVM=YES
WITHOUT_LPR=YES
# WITHOUT_MAIL=YES
WITHOUT_NCP=YES
WITHOUT_NDIS=YES
WITHOUT_OFED=YES
WITHOUT_PF=YES
WITHOUT_PMC=YES
WITHOUT_QUOTAS=YES
WITHOUT_RCMDS=YES
WITHOUT_RCS=YES
WITHOUT_SHAREDOCS=YES
WITHOUT_TESTS=YES
# WITHOUT_USB=YES
WITHOUT_WIRELESS=YES
# WITHOUT_ZFS=YES
```

And /etc/make.conf

```
CPUTYPE?=opteron-sse3
CFLAGS=-O2 -pipe
COPTFLAGS=-O2 -pipe
MALLOC_PRODUCTION=yes

MAKE_JOBS_NUMBER=8
KERNCONF=BSDSERV
WITH_PKGNG=yes

DISABLE_VULNERABILITIES=yes
DEFAULT_VERSIONS= perl5=5.24 ruby=2.3

COMPILER_TYPE=clang
```


----------



## goshanecr (Nov 23, 2018)

Please friends! Tell me how can I try to solve that problem? If there is no solution, I can reinstall system, it is not hard, but FreeBSD as I think can be repaired


----------



## ShelLuser (Nov 23, 2018)

Seriously? You expect a response within the hour?

Dude, have some patience. We don't get paid to help out other people, this is all a voluntary effort and most of us do this because we take some pleasure from it. I can't speak for others (obviously) but I do have my standards and (self implied) rules, one of which is that I do what I do on my own accord and my own choosing.

Just to be sure: This is just my own, personal, opinion on all this. I definitely don't speak on behalf of others. Even so, seriously, have some patience. Reactions like these usually make me ignore the thread entirely or, in this case, vent a little (I blame the weekend for that, definitely not my 'orange' juice ). Whatever that's worth.

First...  src.conf isn't a toggle. Those YES entries are meaningless, you can stick with the = and that's it.

Second... make.conf is a mess.


goshanecr said:


> ```
> WITH_PKGNG=yes
> ```


This has become a bogus entry over time. It was useful when we went to 10.x and pkgng but lost all its meaning over time. It is important to keep up with recent developments and don't leave lingering options.

COMPILER_TYPE isn't a valid option as far as I can tell *** and even if it is the default is Clang anyway. Don't use options which are of no (or little) use, that helps prevent possible problems.



goshanecr said:


> ```
> DISABLE_VULNERABILITIES=yes
> ```


Seriously? You don't mind vulnerabilities at all and don't want to be reminded of them?

For the record: yes, I am a bit of a drama queen here, I fully admit. But that's only because I don't use this option myself and I know what I am talking about, something you can't say for yourself.

Alas; I'll get to the rest later on. I'm also suspicious of WITHOUT_KERNEL_SYMBOLS but I'll need to look into that a bit closer.


----------



## goshanecr (Nov 24, 2018)

ShelLuser said:


> Seriously? You expect a response within the hour?
> 
> Dude, have some patience. We don't get paid to help out other people, this is all a voluntary effort and most of us do this because we take some pleasure from it. I can't speak for others (obviously) but I do have my standards and (self implied) rules, one of which is that I do what I do on my own accord and my own choosing.
> 
> Just to be sure: This is just my own, personal, opinion on all this. I definitely don't speak on behalf of others. Even so, seriously, have some patience. Reactions like these usually make me ignore the thread entirely or, in this case, vent a little (I blame the weekend for that, definitely not my 'orange' juice ). Whatever that's worth.


*ShelLuser* sorry if I'm annoying, just all broks in some minutes and I have some panic  Thanks for your help and your time wasted here in a fridays evening 



ShelLuser said:


> This has become a bogus entry over time. It was useful when we went to 10.x and pkgng but lost all its meaning over time. It is important to keep up with recent developments and don't leave lingering options.


 yes, that option from 10.x times



ShelLuser said:


> COMPILER_TYPE isn't a valid option as far as I can tell *** and even if it is the default is Clang anyway. Don't use options which are of no (or little) use, that helps prevent possible problems.


 that option I'm add today, because after `make installworld` and reboot system starts to tell me 
	
	



```
CC=cc in unknown compiler
```
 and such option silence shows on output of error and I'm set it. After that such errors gone.



ShelLuser said:


> Seriously? You don't mind vulnerabilities at all and don't want to be reminded of them?
> 
> For the record: yes, I am a bit of a drama queen here, I fully admit. But that's only because I don't use this option myself and I know what I am talking about, something you can't say for yourself.
> 
> Alas; I'll get to the rest later on. I'm also suspicious of WITHOUT_KERNEL_SYMBOLS but I'll need to look into that a bit closer.



Yes, yes and 100 more times yes, you a right! I have a mess in config files and I'm not very pedantic user  But I want to repair my system 

Thank's again for your help!


----------



## goshanecr (Nov 24, 2018)

Now I do so steps:

```
1. boot with old kernel (done)
2. grab src-tree from another 11.2 machine (because svnlite not works) (done)
3. make buildworld && make kernel (in process)
(build environment is a 12-STABLE world with 11.1-STABLE kernel :))
```

So it will be 11.2-STABLE from 17 November, hope it will work.


----------



## kpa (Nov 24, 2018)

Your configuration is very very advanced with lots of stuff excluded, it's likely that such configurations haven't been tested by many, not even by the developers. You can't just disable stuff all around and expect your custom configuration to work everytime. If I were you I'd just go back to a very simple configuration, you get very little gains from disabling the base system components, you save maybe some minuscule amount of disk space but those customization have zero impact on performance.


----------



## goshanecr (Nov 24, 2018)

Friends! Problem solved with rebuilding all to 11.2-STABLE (r340490). 
Upgrading to 12.0 I will on next holidays, these are filled enough with that problem 

I think there is some problem with direct upgrading from 11.1-STABLE (r324932) to 12-STABLE
Thanks to all for answers!


----------



## gsimon75 (Jan 7, 2019)

I got that "amd64/arm64/i386 kernel requires linker ifunc support" error right now, and after some grepping found that it's because my default linker is ld.bfd, and /usr/src/share/mk/bsd.linker.mk adds the 'ifunc' feature only for non-bfd linkers: 


```
# ...
${X_}LINKER_FEATURES=
.if ${${X_}LINKER_TYPE} != "bfd" || ${${X_}LINKER_VERSION} > 21750
${X_}LINKER_FEATURES+=  build-id
${X_}LINKER_FEATURES+=  ifunc
.endif
.if ${${X_}LINKER_TYPE} != "lld" || ${${X_}LINKER_VERSION} >= 50000
${X_}LINKER_FEATURES+=  filter
.endif
.if ${${X_}LINKER_TYPE} == "lld" && ${${X_}LINKER_VERSION} >= 60000
${X_}LINKER_FEATURES+=  retpoline
.endif
# ...
```

The other available linker is ld.lld:

```
$ ls -l /usr/bin/ld*
-r-xr-xr-x  2 root  wheel   1458440 Dec 19 07:09 /usr/bin/ld
-r-xr-xr-x  2 root  wheel   1458440 Dec 19 07:09 /usr/bin/ld.bfd
-r-xr-xr-x  1 root  wheel  33500680 Dec 19 07:09 /usr/bin/ld.lld
```

So I tried 'export LD=ld.lld' before the usual 'make cleandepend && make depend && make', and it seems working.

Though your issue seems a bit different, maybe this will help someone who just googled for the error and ended up here .


----------



## n1tr0us (Apr 27, 2019)

gsimon75 said:


> I got that "amd64/arm64/i386 kernel requires linker ifunc support" error right now, and after some grepping found that it's because my default linker is ld.bfd, and /usr/src/share/mk/bsd.linker.mk adds the 'ifunc' feature only for non-bfd linkers:
> 
> 
> ```
> ...


grismon75,
Thank you very much! It's was helpful for me. Was the same isssue...


----------



## olafz (May 2, 2019)

Just curious, should it be enough to define 
	
	



```
WITH_LLD_IS_LD=YES
```
 in src.conf?


----------

