FS#70125 - [root] 6.22.06-5 "symbol unresolved while linking" for glibc calls

Attached to Project: Community Packages
Opened by Maximilian Lehmann (konsonanz) - Monday, 22 March 2021, 07:52 GMT
Last edited by Konstantin Gizdov (kgizdov) - Thursday, 25 March 2021, 12:19 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Konstantin Gizdov (kgizdov)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
While trying to execute a call to standard glibc functions I get "symbol unresolved while linking"
even though the `#include` statement for the header succeeds.
The same is true for other included packages in the makedepend such as openssl etc.
I tested the same procedure on an ubuntu docker image and the call works there,
leading me to believe that this is undesired behaviour for the arch package.

Additional info:
* root-6.22.06-5
* tested with docker image rootproject/root:6.22.06-arch
* tested on host system with root-6.22.06-5 (which is newer than the docker image)

Steps to reproduce:
Demonstrating failing behaviour using the official archlinux based docker image (to demonstrate reproducability):
```
▲ docker run --rm -ti rootproject/root:6.22.06-arch
------------------------------------------------------------------
| Welcome to ROOT 6.22/06 https://root.cern |
| (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Nov 27 2020, 15:14:08 |
| From tags/v6-22-06@v6-22-06 |
| Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------------

root [0] #include "crypt.h"
root [1] crypt("password", "$6$salt")
IncrementalExecutor::executeFunction: symbol 'crypt' unresolved while linking [cling interface function]!
root [2]
```

Demonstrating succeeding behaviour using the official ubuntu based docker image:
```
▲ docker run --rm -ti rootproject/root:6.22.06-ubuntu20.04
------------------------------------------------------------------
| Welcome to ROOT 6.22/06 https://root.cern |
| (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Nov 27 2020, 15:14:08 |
| From tags/v6-22-06@v6-22-06 |
| Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------------

root [0] #include "crypt.h"
root [1] crypt("password", "$6$salt")
(char *) "$6$salt$IxDD3jeSOb5eB1CX5LBsqZFVkJdido3OUILO5Ifz5iwMuTS4XMS130MTSuDDl3aCI6WouIL9AjRbLCelDCy.g."
root [2]
```
This task depends upon

Closed by  Konstantin Gizdov (kgizdov)
Thursday, 25 March 2021, 12:19 GMT
Reason for closing:  Fixed
Additional comments about closing:  root-6.22.08-1 comes with a temporary workaround
Comment by Konstantin Gizdov (kgizdov) - Wednesday, 24 March 2021, 14:06 GMT
This seems to be related to the docker image that ROOT provides, not to the root package in Arch. Is this correct? Can you reproduce this with root in the Arch Linux repos?
Comment by Konstantin Gizdov (kgizdov) - Wednesday, 24 March 2021, 14:14 GMT
The lib path is different on Arch for ROOT (/usr/lib/root) and the library (libcrypt.so) is not located in that path. The following works:
$ root
------------------------------------------------------------------
| Welcome to ROOT 6.22/06 https://root.cern |
| (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
| Built for linuxx8664gcc on Nov 27 2020, 15:14:08 |
| From tags/v6-22-06@v6-22-06 |
| Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------------

root [0] gSystem->Load("/usr/lib/libcrypt.so")
(int) 0
root [1] crypt("password", "$6$salt")
(char *) "$6$salt$IxDD3jeSOb5eB1CX5LBsqZFVkJdido3OUILO5Ifz5iwMuTS4XMS130MTSuDDl3aCI6WouIL9AjRbLCelDCy.g."
root [2]
Comment by Konstantin Gizdov (kgizdov) - Thursday, 25 March 2021, 11:45 GMT
Actually, upon further investigation this is an upstream bug. The issue has been upstreamed partially here - https://sft.its.cern.ch/jira/browse/ROOT-9758 and will need further code review. For the moment a temporary workaround will come in root-6.22.08-1.

Loading...