Help needed: Build errors.

[ISHIKAWA,chiaki]

I need a help.

I create patches for TB and test locally under Debian GNU/Linux.
I use M-C/C-C tree for local TB build and testing.

Background: I have to modify M-C portion of the code although I am
interested in patching C-C TB code.
The reason is that I apply rather strict compiler warning/error
options, and I apply then to ALL the directories including M-C tree.
(It is not entirely clear how I can change the per directory setting
of compiler options. I basically override the default specification by
passing compiler option flags to the CC and CXX commands.)

Some code in M-C tree have issues with sign vs unsigned comparison and
unused variable and they are deemed as compile-time errors with my
strict compiler options, and thus I have to modify M-C tree portion a
bit to avoid the issues.

The build failure.:

Since I updated the M-C/C-C source tree in late December (I have not
for a few weeks), I got the following error during local build and
cannot proceed. (Well, actually the issue in Q2 below popped up first.)

error: the listed checksum of
`/NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/glslopt/glsl-optimizer/src/util/blob.c`
has changed:
expected: 8f729846f66efc9c15485cc5fc24c6ec861fc1fecb2f652573f2a237d481b791
actual: 5d7fb6253f80f0fe4ff98d52a9b73fda6536007634e55a2b7cb7fd36b1e2d963
directory sources are not intended to be edited, if modifications are
required then it is recommended that `[patch]` is used with a forked
copy of the source

Q1: My question is exactly which file should be changed and how the
entry should look
like?

I think the file to change is the following
File:
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/glslopt/.cargo-checksum.json

This has the checksum of blob.c
(I wish the file has a new line after each checksum. It must have been
autogenerated.)
I wonder manual-editing of the said json file is the way to go.
It seems there is a better way with this `[patch]' option. But HOW?

There is also a file called
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/third_party/rust/glslopt/Cargo.toml


Q2

Actually I encountered a similar checksum issue before and had patched
the TOP-LEVEL Cargo.toml. That has probably hid the issue until
December, but I had to back it out temporarily because I got the
following error now.

error: the lock file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/Cargo.lock needs
to be updated but --frozen was passed to prevent this
If you want to try to generate the lock file without accessing the
network, remove the --frozen flag and use --offline instead.

(I now backed out the Cargo.lock file modification due to this error,
and I think this caused the manifestation of the checksum error in Q1
again.)

QUESTION: Where on earth does one specify "--offline" instead of
"--frozen"?

Any tips regarding these two issues will be appreciated.

I am afraid that mozilla documentation is a bit sparse for people who
build and test locally. (Sorry, if they are now explained
somewhere. Last time I checked, they were not.)

TIA

Chiaki

[Gabriele Svelto]

On 05/01/22 08:55, ISHIKAWA,chiaki wrote:
> (I now backed out the Cargo.lock file modification due to this error,
> and I think this caused the manifestation of the checksum error in Q1
> again.)
>
> QUESTION: Where on earth does one specify "--offline" instead of
> "--frozen"?

It's happening here IIRC:

https://searchfox.org/mozilla-central/rev/fbf1e796ecead9484deced4d99f199f327ba25ab/config/makefiles/rust.mk#27

However I'm unsure if that will be enough to fix your problem. Modifying
those sources locally is tricky since they are vendored.

Gabriele

[ISHIKAWA,chiaki]

On 2022/01/05 19:39, Gabriele Svelto wrote:
> On 05/01/22 08:55, ISHIKAWA,chiaki wrote:
>> (I now backed out the Cargo.lock file modification due to this error,
>> and I think this caused the manifestation of the checksum error in Q1
>> again.)
>>
>> QUESTION: Where on earth does one specify "--offline" instead of
>> "--frozen"?
>
> It's happening here IIRC:
>
> https://searchfox.org/mozilla-central/rev/fbf1e796ecead9484deced4d99f199f327ba25ab/config/makefiles/rust.mk#27
>
>

Thank you for the hint.

> However I'm unsure if that will be enough to fix your problem.
> Modifying those sources locally is tricky since they are vendored.
>

This I have to figure out. Before, I simply changed some Cargo file(s)
and all was well.

The change was now refused by --frozen flag.


>  Gabriele


Thank you again.

I will see how far I can proceed.

Stay tuned. :-)

Chiaki

[Steve Fink]

On 1/4/22 23:55, ISHIKAWA,chiaki wrote:

I need a help.

I create patches for TB and test locally under Debian GNU/Linux.
I use M-C/C-C tree for local TB build and testing.

Background: I have to modify M-C portion of the code although I am
interested in patching C-C TB code.
The reason is that I apply rather strict compiler warning/error
options, and I apply then to ALL the directories including M-C tree.
(It is not entirely clear how I can change the per directory setting
of compiler options. I basically override the default specification by
passing compiler option flags to the CC and CXX commands.)

I'm no expert, but I believe you can apply compiler flags to an entire subtree from the top directory's moz.build file. https://firefox-source-docs.mozilla.org/build/buildsystem/mozbuild-files.html#reading-and-traversing-moz-build-files

For example, I have this in js/src/moz.build:

   CXXFLAGS += ["-fstandalone-debug"]

and it apples to everything under js/src/**, including subdirectories with their own moz.build files.

[Dzmitry Malyshau]

You should be able to add a cargo override pointing to the very third-party it's vendored in.

Try this in the root cargo toml (i.e. "/NEW-SSD/NREF-COMM-CENTRAL/mozilla/Cargo.toml"):

[patch.crates-io.glslopt]
path = "third_party/rust/glslopt"

Then `mach vendor rust` and you should be good to go.

-Dzmitry

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/ba842412-5cfc-d768-a87e-bb037e41a31f%40yk.rim.or.jp.

[Jon Bauman]

Chiaki,

In case you're still having trouble, you might find this information useful: https://searchfox.org/mozilla-central/source/media/mp4parse-rust/README.md

I think Dzmitry's suggestion of pointing the patch to third_party/rust/glslopt should work, but I seem to recall having some issues doing that kind of thing with the Cargo.toml patch directive, which may work better with directly overriding the path on the dependency entry directly.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHnMvnKM9-603aY4zhvRFRqNkGbFR_GdJD1LS6746ThPfcZEUA%40mail.gmail.com.

[ISHIKAWA,chiaki]

I have to change rust.mk#27 line to include --offline.
This eliminated the error about the change to Cargo file(s).

However, even with this flag, if I want to change Cargo file to use
[patch...] file to ignore the
local change, the error resurfaces.

Finally, I had to edit the checksum file to use the
checksum of the locally modified file.
Then the problem disappears.

Thank you again.

Chiaki

PS: However, the compilation did not proceed due to gettid() issue,
which I will post later.

[ISHIKAWA,chiaki]

Thank you for the tips!

Aha, I probably missed this step:

> Then `mach vendor rust` and you should be good to go.

Now I figure that this is something I have to do after adding

> [patch.crates-io.glslopt]
> path = "third_party/rust/glslopt"

Since I could not eliminate the error somehow (by not doing the |mach
vendor rust| even modifying rust.mk file, I edited
the checksum file directly. Ugly although  it works.
But I would follow your steps to make my local changes manageable.

Thank you again.

Chiaki

> <mailto:dev-platform%2Bunsu...@mozilla.org>.

> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/ba842412-5cfc-d768-a87e-bb037e41a31f%40yk.rim.or.jp.
>
> --
> You received this message because you are subscribed to the Google
> Groups "dev-pl...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to dev-platform...@mozilla.org.
> To view this discussion on the web visit

> https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHnMvnKM9-603aY4zhvRFRqNkGbFR_GdJD1LS6746ThPfcZEUA%40mail.gmail.com
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHnMvnKM9-603aY4zhvRFRqNkGbFR_GdJD1LS6746ThPfcZEUA%40mail.gmail.com?utm_medium=email&utm_source=footer>.