Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[ARM64]bad file descriptors everywhere...
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
laizzn
n00b
n00b


Joined: 24 Feb 2015
Posts: 24

PostPosted: Mon May 14, 2018 12:15 pm    Post subject: [ARM64]bad file descriptors everywhere... Reply with quote

Hi
I tried to update my raspberry 3 today, and now I have error messages everywhere.
It starts when ssh'ing to raspi: I now suddenly get twice this error:

Code:
bash: warning: setlocale: LC_NUMERIC: cannot change locale (...): Invalid argument


sometimes when I sudo or just try eix, or anything else, I get logged out:

Code:
eix -I io
logout
[1]+  Stopped


Besides, I cannot install anything as I always get 'bad file descriptors errors':

Code:
>>> Running pre-merge checks for sys-libs/glibc-2.26-r6
make -j16 -l4 -s glibc-test
make: *** sigprocmask(SIG_SETMASK, SIGCHLD): Bad address.  Stop.
emake failed
 * Simple build failed ... assuming this is desired #324685
make -j16 -l4 -s glibc-test
make: *** sigprocmask(SIG_SETMASK, SIGCHLD): Bad address.  Stop.
emake failed
 * Simple build failed ... assuming this is desired #324685

 * Messages for package sys-libs/glibc-2.26-r6:

 * Simple build failed ... assuming this is desired #324685
 * Simple build failed ... assuming this is desired #324685
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.5/emerge", line 50, in <module>
    retval = emerge_main()
  File "/usr/lib64/python3.5/site-packages/_emerge/main.py", line 1264, in emerge_main
    return run_action(emerge_config)
  File "/usr/lib64/python3.5/site-packages/_emerge/actions.py", line 3298, in run_action
    retval = action_build(emerge_config, spinner=spinner)
  File "/usr/lib64/python3.5/site-packages/_emerge/actions.py", line 540, in action_build
    retval = mergetask.merge()
  File "/usr/lib64/python3.5/site-packages/_emerge/Scheduler.py", line 1001, in merge
    signal.siginterrupt(signal.SIGCONT, False)
OSError: [Errno 9] Bad file descriptor


I wanted to downgrade to glibc-2.26-r6 since I only got buggy after this morning's updates when I installed sys-libs/glibc-2.26-r7, I guess..
any help appreciated...
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46756
Location: 56N 3W

PostPosted: Mon May 14, 2018 5:57 pm    Post subject: Reply with quote

laizzn,

Downgrading glibc is usually a very bad thing and the eclass won't let you.
If you are really sure you want to do this there is a Pi3 arm64 BINHOST you can get a binary tarball from.

I've broken glibc with distcc before too. I guess
Code:
make -j16 -l4 -s glibc-test
isn't a native build?

You may need the tar method.

If tar is broken because it depends on a broken glibc, busybox tar might stii work
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Sakaki
Guru
Guru


Joined: 21 May 2014
Posts: 409

PostPosted: Mon May 14, 2018 8:57 pm    Post subject: Reply with quote

arm64 glibc seems to react badly to being built partially locally, partially remotely with distcc (see e.g. this post), even though a 'pure' cross-compile or native build of the same version works.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
laizzn
n00b
n00b


Joined: 24 Feb 2015
Posts: 24

PostPosted: Tue May 15, 2018 9:11 am    Post subject: Reply with quote

sounds bad :cry: maybe i'll try to rescue it ...

but thanks for both for your help.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46756
Location: 56N 3W

PostPosted: Tue May 15, 2018 10:11 am    Post subject: Reply with quote

laizzn,

Its not that bad. Put the SDcard in a real PC and mount the arm64 gentoo at /mnt/gentoo. Don't chroot :)
Fetch the binary from my BINHOST, Sakakis distro or unpick the arm64 stage3.

Run
Code:
tar -xpf /path/to/tarball -C /mnt/gentoo


That unpacks the tarball to /mnt/gentoo using tar from the PC.
Forgetting the
Code:
 -C /mnt/gentoo
might ruin your whole day and PC install, depending on your $PWD as it will install the arm64 code there.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7466

PostPosted: Tue May 15, 2018 11:29 am    Post subject: Reply with quote

It's because of pump mode.
man distcc wrote:
In pump mode, therefore, distcc gathers all of
the recursively included headers, except the ones that are default system headers, and sends them along with the
source file to the compilation server.

What this mean is that if arm host need build project Z and it need "default system headers", the ones in use will be the ones from the build host, and not the ones from the arm.
Portage use the root= directive when use with crossbuild tool to help anyone aiming at /usr/include in fact aiming at the right /usr/"chost-tuppple/usr/include directory.

When you use distcc to cross build it doesn't do that, it works because the host "gcc" is redirect to use "chost-tupple_gcc" and this chost_tupple_gcc is the good gcc to use on the build host, so distcc works. But it doesn't chroot anything unlike crossbuild tool is doing with emerge.

What this mean is that, this is what is going on when you build program Z that need headers /usr/include/linux/a.out.h and /usr/include/x264.h
non pump:
buildhost: gcc program Z
armhost: linking program Z result with /usr/include/linux/a.out.h and /usr/include/x264.h

in pump mode:
buildhost: gcc program Z
buildhost: linking program Z result of "some_distcc_tmp_directory/armhost-x264.h" (this non standard headers was sent by distcc pump) and "/usr/include/linux/a.out.h" (this one "standard header" is not sent but taken from the build host)
armhost: end up with that program Z build against headers not own by the arm host

with crossbuild tool:
buildhost: gcc program Z
buildhost: linking program Z result with "/usr/include/linux/a.out.h" that is from /usr/chost-tupple/usr/include/linux/ and /usr/include/x264.h that is from /usr/chost-tupple/usr/include/linux/x264.h ; because the paths are root from /usr/chost-tupple.

So pump mode to cross build any project is a bad idea. If anyone wants do that he should make sure chost-tupple-gcc not only branch to the right gcc, but also force a chroot (or bind) to use any default headers taken from /usr/chost-tupple/include path and never ones from /usr/include ; the build host must also make sure /usr/chost-tupple/include strictly match the ones from the arm box.

Note however i'm assuming /usr/include as "default system headers", because no matter how i have search, distcc never tell where and what are exactly these "default system headers". I think at least /usr/include/linux is one of them, but more may be taken from /usr/include (and i assume at least everything from linux-headers content)

as sad as it is, you should never use pump with cross building except if you know that no standard headers will be use (meaning that everything the build host will link against was given by distcc)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46756
Location: 56N 3W

PostPosted: Tue May 15, 2018 11:49 am    Post subject: Reply with quote

krinn,

It mostly works most of the time, even glibc.
I have not been able to predict when pump mode cross distcc will fail.
Different versions of gcc produce broken binaries but that's well known. Its much more subtle than that.

Using common system headers should be harmless as they are arch agnostic.
Using common system headers that differ in versions between the arches involved might be an issue as the foreign headers may not match the common system libs come link time back on the arm64. Then the wheel comes off.

Avoiding pump mode as you suggest, is certainly safer but its a tradeoff.
Picking up the pieces is difficult once you have trashed a lot of packages.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7466

PostPosted: Tue May 15, 2018 12:03 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Different versions of gcc produce broken binaries but that's well known. I

I agree it is even worst for gcc different versions because of gcc's "fixes"
But many users just also forget that upgrading headers should always be followed by rebuilding gcc ; and it is the worst of the worst because checking both headers and gcc version, and they match. (user install gcc-1, gcc-1 fix headers-1, user upgrade to headers-2, gcc-1 is not rebuild, headers-2 doesn't use gcc fixes : but if you compare, both machine have the same gcc-1 and headers-2 install, but one have a fixed headers-2 and the second use stock version).

The only good thing to this is that arm users should always set and use usepkg, but it seems that is was obvious only for me, and it seems laizzn is lacking the feature.
With space limit and hdd speed constrains, i could understand why some users may not wish usepkg features on arm, but really guys, nfsd could hold this for you, because the build host certainly have plenty space to share with the arm one.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum