You should start a new thread for this kind of question, rather than
replying to this one.
Additionally, if you're modifying Abseil, I don't think this question has
anything to do with Chromium. You could try asking on an Abseil discussion
group, but I suspect you're on your own, since you're modifying APIs meant
for internal Abseil use only.
On Mon, Dec 12, 2022 at 9:00 AM wei cheng <chengwe...@gmail.com> wrote:
> Hi,
>
> I want to use randen_engine, so I add code in
> \third_party\abseil-cpp\absl\random\random.h
>
> // Make randen_engine available for direct usage, because
> // absl::BitGen/InsecureBitGen uses always-on process-bound salt for seeded
> // generators.
> template <typename T>
> using randen_engine = random_internal::randen_engine<T>;
>
>
> then in my codes,
> \third_party\blink\renderer\core\farbling\brave_session_cache.h
> typedef absl::randen_engine<uint64_t> FarblingPRNG;
>
> third_party\blink\renderer\core\farbling\brave_session_cache.cc
> int BraveSessionCache::FarbledInteger(FarbleKey key,
> int spoof_value,
> int min_random_offset,
> int max_random_offset) {
> if (farbled_integers_.count(key) == 0) {
> FarblingPRNG prng = MakePseudoRandomGenerator(key);
> farbled_integers_[key] =
> prng() % (1 + max_random_offset - min_random_offset) +
> min_random_offset;
> }
> return farbled_integers_[key] + spoof_value;
> }
>
> but failed as below
> c:\code\chromium_git\chromium\src>ninja -C out\Release_GN_x86 cef
> ninja: Entering directory `out\Release_GN_x86'
> [0/1] Regenerating ninja files
> [10/23] LINK v8_context_snapshot_generator.exe
> v8_context_snapshot_generator.exe.pdb
> FAILED: v8_context_snapshot_generator.exe
> v8_context_snapshot_generator.exe.pdb
> ninja -t msvc -e environment.x86 --
> ..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe /nologo
> -libpath:..\..\third_party\llvm-build\Release+Asserts\lib\clang\12.0.0\lib\windows
> "-libpath:..\..\..\..\..\..\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.28.29910\ATLMFC\lib\x86"
> "-libpath:..\..\..\..\..\..\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.28.29910\lib\x86"
> "-libpath:..\..\..\..\..\..\Program Files (x86)\Windows
> Kits\10\lib\10.0.19041.0\ucrt\x86" "-libpath:..\..\..\..\..\..\Program
> Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x86"
> /OUT:./v8_context_snapshot_generator.exe
> /PDB:./v8_context_snapshot_generator.exe.pdb
> @./v8_context_snapshot_generator.exe.rsp
> lld-link: error: undefined symbol: public: __thiscall
> absl::random_internal::Randen::Randen(void)
> >>> referenced by
> .\..\..\third_party\blink\renderer\core\farbling\brave_session_cache.cc:357
> >>> blink_core.lib(brave_session_cache.obj):(public: bool
> __thiscall brave::BraveSessionCache::AllowFontFamily(class
> blink::WebContentSettingsClient *, class WTF::AtomicString const &))
> >>> referenced by
> .\..\..\third_party\blink\renderer\core\farbling\brave_session_cache.cc:343
> >>> blink_core.lib(brave_session_cache.obj):(public: int
> __thiscall brave::BraveSessionCache::FarbledInteger(enum brave::FarbleKey,
> int, int, int))
> >>> referenced by
> .\..\..\third_party\blink\renderer\core\farbling\brave_session_cache.cc:329
> >>> blink_core.lib(brave_session_cache.obj):(public: class
> WTF::String __thiscall brave::BraveSessionCache::FarbledUserAgent(class
> WTF::String))
> >>> referenced 1 more times
>
> what should I do to fix it? thankx
> 在2020年8月5日星期三 UTC+8 22:52:31<jbr...@chromium.org> 写道：
>
>> The restrictions should largely be similar to using STL and base types --
>> where there are reasons that WTF has provided something else, the WTF one
>> should probably be used (for example, string and collection types). Aside
>> from those anything that's good in Chromium should be fine.
>>
>> On Wed, Aug 5, 2020 at 4:42 AM Yutaka Hirano <yhi...@chromium.org> wrote:
>>
>>> -chromium-dev, -cxx
>>>
>>> We have some restrictions on the use of base/ in blink. Do we have a
>>> similar policy for abseil?
>>>
>>> On Sat, Aug 1, 2020 at 7:10 AM 'Peter Kasting' via cxx <
>>> c...@chromium.org> wrote:
>>>
>>>> Chromium contributors (and bcc abseil-io as FYI),
>>>>
>>>> *TLDR: *It's now possible to use Abseil in first-party Chromium code.
>>>>
>>>> - Only absl::variant is currently allowed.
>>>> - See http://chromium-cpp.appspot.com/ for the current status of
>>>> features. To request more features, email c...@chromium.org.
>>>> - To use an allowed feature, have your target depend appropriately
>>>> on "//third_party/abseil-cpp:absl", and #include the relevant
>>>> header from third_party/abseil-cpp/absl/.
>>>>
>>>> *Longer version follows*
>>>>
>>>> As of today, first-party code in Chromium is allowed to use Abseil. As
>>>> with new versions of the C++ standard, support is initially restricted to
>>>> features which are explicitly allowlisted; consideration of a feature is by
>>>> request. To begin with, absl::variant is the only allowed feature.
>>>>
>>>> *To use an Abseil feature in your code:*
>>>>
>>>> - #include the relevant header(s) from third_party/abseil-cpp/absl/.
>>>> For example, #include "third_party/abseil-cpp/absl/types/variant.h".
>>>> - In the relevant BUILD.gn, add "//third_party/abseil-cpp:absl" to
>>>> your target's deps or "public_deps" as appropriate. Because of
>>>> visibility restrictions designed to hinder inappropriate use, you will
>>>> need
>>>> to use public_deps if your #include is in a .h that another target
>>>> #includes.
>>>>
>>>> *To see or request allowed features:*
>>>>
>>>> - To see the current status of features, visit
>>>> http://chromium-cpp.appspot.com/. Some features are explicitly
>>>> banned for various reasons; most remain banned-by-default as "TBD".
>>>> - To request consideration of a TBD or banned feature, mail
>>>> c...@chromium.org, ideally with a use case and relevant context.
>>>> - After two years, style arbiters will explicitly allow or ban all
>>>> remaining TBD features.
>>>>
>>>> *FAQ:*
>>>>
>>>> - *What about third-party code?*
>>>> - Code in third_party can use Abseil freely, except for features
>>>> explicitly banned due to incompatibility; code that needs those
>>>> features is
>>>> allowed if it won't actually cause problems. Contact cxx@ for
>>>> more information.
>>>> - *What do you mean, incompatibility? And why are there weird
>>>> visibility restrictions?*
>>>> - Certain Abseil features (e.g. absl::any, ABSL_FLAG) rely on
>>>> either RTTI (which Chromium disables) or a workaround called
>>>> FastTypeId that isn't compatible with the component build. Using
>>>> such features risks subtle bugs when code compiles and links but
>>>> doesn't
>>>> behave as expected, so these are banned from being linked into
>>>> Chromium.
>>>> - Partly to enforce these bans, both the .gn and DEPS files have
>>>> various restrictions (such as include_rules and visibility
>>>> adjustments) designed to hinder accidental misuse. It's not
>>>> impossible, but
>>>> hopefully we made it hard to accidentally blow your leg off.
>>>> - *What about first-party code that needs to interact with
>>>> third-party code that uses types Chromium doesn't currently allow?*
>>>> - Assuming the third-party use is otherwise allowed (see above),
>>>> you are allowed to use banned features as minimally necessary at the
>>>> third-party code boundary to interface with it. Convert to Chromium
>>>> types/features/etc. as early as possible. Contact cxx@ for more
>>>> information.
>>>> - *Will we be replacing base:: types like Span and Optional with
>>>> absl:: ones?*
>>>> - All other things being equal, we would slightly prefer to use
>>>> an absl:: type to an identical base:: one. That's one less
>>>> thing we have to maintain, and we trust the Abseil team.
>>>> - For cases like Span, the base:: type is more std::-compliant
>>>> than the absl:: one. Since in such cases our ultimate goal would
>>>> be to move to the std:: type, we won't migrate to absl:: unless
>>>> compliance improves to at least match base::.
>>>> - For cases like time handling where there are significant
>>>> design/API differences, we'd need a compelling reason to migrate
>>>> existing
>>>> code, since a migration plan would be significantly more complicated.
>>>> - In the other cases, we won't migrate unless there's a
>>>> migration plan (and responsible owner(s)). The default plan is "make
>>>> base:: API match absl::; change base:: implementation to be an
>>>> alias; replace usage of base:: with absl:: everywhere; remove
>>>> base:: implementation". Those steps aren't free, and someone
>>>> needs to be willing to pay the cost.
>>>> - *When Chromium supports C++17, will we replace absl:: types
>>>> with std:: ones?*
>>>> - Yes, assuming we can do so without regressing security
>>>> guarantees. We have various hardening tests that ensure certain
>>>> misuses
>>>> cause checkfailures. We won't migrate code to STL implementations
>>>> that
>>>> don't provide at least equivalent checks we can enable. The most
>>>> likely
>>>> path in many cases is that libc++ adds such checks. I'm sure
>>>> pal...@chromium.org would love to talk to you about this. :D
>>>> - *Something something Chromium C++14 Abseil support guarantees
>>>> NaCl toolchain compatibility something uh oh?*
>>>> - If you have no idea what this question could be about, you
>>>> don't need to worry about it.
>>>> - Leadership on various sides have made commitments that should
>>>> ensure it's safe to start relying on Abseil, and we won't get stuck
>>>> in a
>>>> year or two with libraries that stop working, unsupported code, etc.
>>>> I
>>>> don't know what all is public so that's all I'll say.
>>>> - *Why can't I use ___________ from Abseil yet?*
>>>> - Likely because we haven't formally considered it. Propose it
>>>> per instructions above.
>>>> - To make sure we don't unintentionally cause catastrophe, we
>>>> reserve the right to slow the adoption rate of even clearly-OK
>>>> features.
>>>> But in the limit that should be weeks, not years.
>>>> - *Abseil is cool, now can I get support for {boost, EASTL,
>>>> $your_favorite_here}?*
>>>> - We'll consider anything reasonable, but no guarantees.
>>>> (Author's note: my recent proposition to add a couple Boost items
>>>> already
>>>> on Google's officially approved list was not met with great
>>>> enthusiasm, if
>>>> this tells you anything.)
>>>> - *pkasting, you're so amazing, I just want to hear more from you.
>>>> Is there anything else you haven't mentioned?*
>>>> - Why yes! Gtest support for Abseil has also been enabled, which
>>>> provides pretty-printers for various types. For example, here's the
>>>> output
>>>> of an EXPECT_EQ() on two absl::variants, one containing
>>>> <bool>(false), and one containing <gfx::Rect>({1, 2, 3, 4}):
>>>>
>>>> *Before:*
>>>> error: Expected equality of these values:
>>>> V(false)
>>>> Which is: 24-byte object <00-F9 63-74 F7-7F 00-00 00-00
>>>> 00-00 FA-00 00-00 01-00 00-00 00-00 00-00>
>>>> c
>>>> Which is: 24-byte object <01-00 00-00 02-00 00-00 03-00
>>>> 00-00 04-00 00-00 02-00 00-00 00-00 00-00>
>>>>
>>>> *After:*
>>>> error: Expected equality of these values:
>>>> V(false)
>>>> Which is: ('<type>(index = 1)' with value false)
>>>> c
>>>> Which is: ('<type>(index = 2)' with value 1,2 3x4)
>>>>
>>>> *Thanks*
>>>>
>>>> - The Abseil team, who have been very helpful in working with
>>>> Chromium to support our needs.
>>>> - mbonadei@ and danilchap@, the people mainly responsible for
>>>> keeping Abseil rolled into Chromium's tree and functioning as desired,
>>>> including testing and adding various things to resolve blockers.
>>>> - cxx@ et al., especially those who sent explicit input on this,
>>>> including (but not limited to) danakj@, jbroman@, jdoerrie@, gab@,
>>>> jam@, dpranke@, dcheng@.
>>>> - If you read this far, you! Hope it was informative.
>>>>
>>>> PK
>>>>
>>>> P.S. OK, I admit, no one asked that last FAQ.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "cxx" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to cxx+uns...@chromium.org.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBcZhhOXwVNaPtF5h82goGqMCFYOGu8k3D1wnYg60bMww%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBcZhhOXwVNaPtF5h82goGqMCFYOGu8k3D1wnYg60bMww%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HpBWHSR9B2-%3DjM%3DvX2j8wnOo-mroanX6JnCJhhg8BqSQ%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HpBWHSR9B2-%3DjM%3DvX2j8wnOo-mroanX6JnCJhhg8BqSQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5885d2a-e202-4e75-ad2f-22e5902080a2n%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5885d2a-e202-4e75-ad2f-22e5902080a2n%40chromium.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACwGi-63U5HRuonFFqM8VDqhYAi125yfF4_WDq_O3qvL6PrPCg%40mail.gmail.com.
