Failed to complete chroot setup

[Oracle8088]

libcras/cras_client.c:1827:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] if (req == (struct floop_request *)tag) ^ libcras/cras_client.c: In function 'request_floop': libcras/cras_client.c:4209:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cras_fill_request_floop(&msg, params, (uint64_t)&req);

cc1: warning: unrecognized command line option '-Wno-int-in-bool-context' /usr/bin/ld: cannot find -lcras collect2: error: ld returned 1 exit status Failed to complete chroot setup.

The above is what i get when attempting to downlaod crouton, which has otherwise worked easy as pie every other time ive used but have since powerwashed my laptop.

I am using

sudo install -Dt /usr/local/bin -m 755 ~/Downloads/crouton sudo crouton -t xfce

[Denis96Gamer]

I also have this issue. I first tried installing Bullseye and it didn't even try to install at all. Also i think Google has to do something with this.

[iptoux]

Fix:

https://github.com/iptoux/crouton/tree/crasfix

installed fine on my side.

[ClaytonTDM]

Please add this to the official build 🙏

[michaelcadilhac]

Any reason why this hasn't been included yet? Can't run crouton -t xfce.

[dnschneid]

Looks like we should just be getting rid of -Wno-int-in-bool-context in https://github.com/dnschneid/crouton/blob/master/targets/audio#L180 since we're doing -Wno-error anyway.

[dnschneid]

Try installing using CROUTON_BRANCH=slowpoke_fixes crouton and let me know if things work

[michaelcadilhac]

Sadly, exact same error.

[dnschneid]

If you're still getting cc1: warning: unrecognized command line option '-Wno-int-in-bool-context', then something's up with how you ran the above command, since the code in that branch no longer includes it. Could you please post the command you ran?

edit: make sure you're putting sudo at the start: sudo CROUTON_BRANCH=slowpoke_fixes crouton

[michaelcadilhac]

Apologies, that warning ain't the problem:

localhost /mnt/stateful_partition/crouton/chroots # CROUTON_BRANCH=slowpoke_fixes /usr/local/bin/crouton -t xfce
[...]
Compiling CRAS (i386)...
libcras/cras_client.c: In function 'request_floop_ready':
libcras/cras_client.c:1827:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   if (req == (struct floop_request *)tag)
              ^
libcras/cras_client.c: In function 'request_floop':
libcras/cras_client.c:4209:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  cras_fill_request_floop(&msg, params, (uint64_t)&req);
                                        ^
/usr/bin/ld: cannot find -lcras
collect2: error: ld returned 1 exit status
Failed to complete chroot setup.
Unmounting /mnt/stateful_partition/crouton/chroots/xenial...

[dnschneid]

Hmm, thanks.

As far as I can tell, there's nothing that should be re-enabling -Werror after we disable it, so it's not clear to me why the build is failing with only warnings. I also don't understand how @iptoux's commit fixes it; maybe he can explain it. I'm tempted to just disable warnings altogether (-w), but it's also possible the warnings are a red herring and something in our automake wrapper is causing the fragility.

Maybe @drinkcat can take a peek?

[iptoux]

@dnschneid Just look on the diff, i replaced the argument, not just removed it.

https://github.com/iptoux/crouton/commit/1c0ca80037394e22bb86c5ba72f6898edc52c5b7

[dnschneid]

Yes, you added -Wint-to-pointer-cast. What I'd like explained is why telling gcc to report warnings for something it's already reporting somehow makes the compilation progress successfully, and why pointer-to-int-cast doesn't need the same treatment. Because if adding that is actually fixing the issue then there's some voodoo gcc behavior going on that I've never heard of.

[drinkcat]

I wonder if there's something in the order in variable expansion in Makefile.am that would cause it to evaluate -Wno-error before -Werror

Maybe adding something like this:

sed -i -e 's/-Werror//' Makefile.am

(we can still remove -Wno-int-in-bool-context and keep -Wno-error in CFLAGS just in case)

And I'm also confused why @michaelcadilhac is not seeing something like cc1: all warnings being treated as errors, so maybe the error is not actually related to -Werror/-Wno-error.

[michaelcadilhac]

Confused too. Is there a way for me to take control of the libcras source directory after the fail, so that I can investigate? I'm not familiar with crouton's architecture, and after a cursory glance, I can't find where these sources are compiled.

[drinkcat]

Yeah it's a little messy. Your best bet to trace this is probably to add a -x to this line: https://github.com/dnschneid/crouton/blob/70e993fbc2cb3df3daf85a569c1c33cb1d9ad6df/targets/audio#L194

} | sh -s -e $SETOPTIONS -x

So that you can see what command is being run.

[drinkcat]

(btw the cras_client warning is being fixed here: https://crrev.com/c/3970965 -- but likely, that's not actually the problem on hand here)

[TomTravis]

the google sources have not changed Crouton has this is why Cras does not compile if you use the rep for the Debootstrap script

It compiles for me just fine, The idea is the src is downloaded from Google chrome and saved in /tmp the file is used to compile the Craslib binary and then removed