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.
