guix build problem, no RUNPATH on libpthread.so

  • Open
  • quality assurance status badge
Details
3 participants
  • Efraim Flashner
  • Michael Zucchi
  • zimoun
Owner
unassigned
Submitted by
Efraim Flashner
Severity
normal
E
E
Efraim Flashner wrote on 21 Apr 2020 07:36
(name . Michael Zucchi)(address . notzed@gmail.com)
20200421053635.GC10788@E5400
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl6ehmIACgkQQarn3Mo9
g1FSXhAAj+cMx1oRjpPG701Ymp60DPIuoUJSnbLceV03iPTk4YE/OQBB+DBEL0Gj
0dWjtkJbcMLDMnjOaD4dytwyoO5p1pqhhlbE3kJdBmyNfzSo26jshlKayURCssOD
G1J7laovsQAQnufAJelEUAfYS1KL5EQarqXtK7Bbha+Gck53cyWtfusq1nzVCG1k
O2HRjPmXEhs3biimVAuJyyTLpp0dJgiAfC+xdMLWlnpdKUojdhwDW5dVgy/6uMcK
Z+rfCqVW+MsUPiwR4EsJAxF8jyQkkeuXbQuBWlSdxpjrmuqOR7BOa+9Xftr3SRiP
VQlKJg52lIazctnKCnb2B04BkUbQTVC6kwrA1AcksTYfbIbYfhVYPD5RutdC2nAD
uOPcTipumrRbqyq5SV+J4sauKo1Ja/Jr697QF2KBMT6wamYj+ayX5gPCrMSGs99k
SC5gceAWy7ovehdFRRBLFAn3thX/j3uoMPW+DqoLfVRMpeBDB7IgAINgaHERa8zc
HM/Bbq9bSX0K4ey3SI/PGRMTHmnLKMgimDTcr50JbhAYfLtaEndbAUjJ0zLjMLBA
QcMfFsxRiGhWYgOMYmRuW9+EWwzRD5EQjjaa8dNZMsLlcEQzFCAebDUBLZ9I6EbU
el3VPmFfPCDacKjf7qvBQFBKvZy7Pt28h+n9eEXDvG0gqYOdx0E=
=yQWl
-----END PGP SIGNATURE-----


Z
Z
zimoun wrote on 21 Apr 2020 09:55
(name . Efraim Flashner)(address . efraim@flashner.co.il)
CAJ3okZ0mDrXbLa17w3D9MuEvzUZcZpSfNYV_ULQkb8irqTzYZA@mail.gmail.com
Dear Michael,

Toggle quote (5 lines)
> On Tue, Apr 21, 2020 at 09:41:47AM +0930, Michael Zucchi wrote:

> > But the first guix pull fails because it tries to run a 32 bit binary, so
> > ultimately fails for the the same reason as detailed in my previous email.

To be sure to understand,
- your machine is 64bit
- and you are running Guix on the top of Slackware
- Guix has been installed using this script
Right?
Then, something screws up and some 32bit stuff shows up, right?

The previous emails related to this topic you mentioned ("I posted
about this months ago but I think I got no answers") in this thread
are [1] and [2], right?



All the best,
simon
M
M
Michael Zucchi wrote on 22 Apr 2020 02:35
379a0838-8c5a-29cf-f8d5-cf9a6d7b2c76@gmail.com
G'day Simon,

On 21/4/20 5:25 pm, zimoun wrote:
Toggle quote (12 lines)
> Dear Michael,
>
>> On Tue, Apr 21, 2020 at 09:41:47AM +0930, Michael Zucchi wrote:
>>> But the first guix pull fails because it tries to run a 32 bit binary, so
>>> ultimately fails for the the same reason as detailed in my previous email.
> To be sure to understand,
> - your machine is 64bit
> - and you are running Guix on the top of Slackware
> - Guix has been installed using this script
> https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
> Right?

Correct although I can't remember if i ran the script or used the steps
in the manual
slackware doesn't use one of the supported init systems and all the
steps it performs are trivial so i might've skipped it.  guix with
substitutions was working ok for the limited use I made of it.

Toggle quote (2 lines)
> Then, something screws up and some 32bit stuff shows up, right?

Well yes and no - nothing screws up and the behaviour is intended it
just doesn't work.   As i found[2] 4 months ago, the bootstrap package
explicitly uses i686 binaries for amd64 because (I presume) they are
statically linked and all amd64 hardware supports executing 32-bit mode
code.  But my linux configuration disables it because i don't need or
want it.

It all happens here:


|(define bootstrap-executable (mlambda (program system) "Return an
origin for PROGRAM, a statically-linked bootstrap executable built for
SYSTEM." ;>>>>>>>>>>>>>>  (let ((system (if (string=? system
"x86_64-linux") "i686-linux" system))) ;<<<<<<<<<<<<<<  (match
(assoc-ref (assoc-ref %bootstrap-executables system) program) (#f (raise
(condition (&message (message (format #f (G_ "could not find bootstrap
binary '~a' \ for system '~a'") program system)))))) ((sha256) (origin
(method url-fetch/executable) (uri (bootstrap-executable-url program
system)) (file-name program) (sha256 sha256))))))) |

||
||
|I attempted modifying this to use 64-bit binaries at the time but it
wouldn't use the ones i supplied when it|
|came to executing the tests.  So I dropped it as it was going nowhere
fast, nobody seemed interested, and had
other things to do like xmas. ||Those failed attempts are long gone.|
||
||
||
Toggle quote (7 lines)
> The previous emails related to this topic you mentioned ("I posted
> about this months ago but I think I got no answers") in this thread
> are [1] and [2], right?
>
> [1] https://lists.gnu.org/archive/html/help-guix/2019-12/msg00111.html
> [2] https://lists.gnu.org/archive/html/help-guix/2019-12/msg00131.html
>
Yeah.

Toggle quote (3 lines)
> All the best,
> simon

Cheers,
 Z
Attachment: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 40740@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40740
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch