Emircan, could you please try executing the build step manually, and gather more information?  With the previous issue, the SEGFAULT was reproducible by simply executing `flatc -c nonexistent`.

The output of the following would be a big help:
  gdb --args $FLATC_COMMAND_LINE ...
  LD_DEBUG=all $FLATC_COMMAND_LINE
  ldd ./flatc
  readelf --dyn-syms ./flatc

Also, could you please specify the exact build configuration you are running?

Below is the stack trace. I am running from Linux but through a virtual env created for CrOS builds. "cros chrome-sdk --board=link"

(sdk link R54-8608.0.0) $ gdb --args ../out_link/Debug/flatc -c -o ../out_link/Debug/gen/flatc_out/components/subresource_filter/core/common/flat "subresource_filter/core/common/flat/rules.fbs"
(gdb) run
Starting program: /work/chromium/src/out_link/Debug/flatc -c -o ../out_link/Debug/gen/flatc_out/components/subresource_filter/core/common/flat subresource_filter/core/common/flat/rules.fbs
Loading gdb's copy of v17 libstdc++ pretty-printers.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7b46d61 in __gthread_once (
    __func=0x7ffff7b46d00 <std::locale::_S_initialize_once()>, __once=<optimized out>)
    at /build/gcc-4.8-mW1ufQ/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu/bits/gthr-default.h:699
#2  std::locale::_S_initialize ()
    at ../../../../../src/libstdc++-v3/src/c++98/locale_init.cc:276
#3  0x00007ffff7b46da3 in std::locale::locale (this=0x7fffffffc158)
    at ../../../../../src/libstdc++-v3/src/c++98/locale_init.cc:210
#4  0x00007ffff7b8af00 in basic_ios (this=0x7fffffffc088)
    at /build/gcc-4.8-mW1ufQ/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:456
#5  std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream (
    this=0x7fffffffbf88, __s=0x4fa238 "subresource_filter/core/common/flat/rules.fbs", 
    __mode=std::_S_bin, __in_chrg=<optimized out>, __vtt_parm=<optimized out>)
    at /build/gcc-4.8-mW1ufQ/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v3/include/fstream:468
#6  0x00000000004b4e11 in flatbuffers::LoadFileRaw (
    name=0x4fa238 "subresource_filter/core/common/flat/rules.fbs", binary=true, 
    buf=0x7fffffffc3c0) at ../../third_party/flatbuffers/src/src/util.cpp:27
#7  0x00000000004b5054 in flatbuffers::LoadFile (
    name=0x4fa238 "subresource_filter/core/common/flat/rules.fbs", binary=true, 
    buf=0x7fffffffc3c0) at ../../third_party/flatbuffers/src/src/util.cpp:49
#8  0x00000000004042d8 in main (argc=5, argv=0x7fffffffc678)
    at ../../third_party/flatbuffers/src/src/flatc.cpp:233

These are the defualt GYP params for this virtual env.

(sdk link R54-8608.0.0) emircan@emircan /work/chromium/src/out_link $ echo $GYP_DEFINES
use_ozone="1" remoting="1" ozone_platform_gbm="1" use_brlapi="1" linux_use_gold_flags="1" chromeos="1" linux_use_debug_fission="0" use_vtable_verify="0" host_clang="1" use_cups="1" disable_nacl="0" use_system_harfbuzz="1" gomadir="/work/chromium/.cros_cache/common/goma+2" use_evdev_gestures="1" use_goma="1" release_extra_cflags="-g" target_arch="x64" clang_use_chrome_plugins="0" system_libdir="lib64" use_cras="1" sysroot="/work/chromium/.cros_cache/chrome-sdk/tarballs/link+8608.0.0+sysroot_chromeos-base_chromeos-chrome.tar.xz" linux_link_libbrlapi="1" use_v4l2_codec="1" use_xkbcommon="1" clang="0" linux_use_bundled_binutils="0" use_v4lplugin="0" linux_use_bundled_gold="0" icu_use_data_file_flag="1" asan="0" use_system_minigbm="1" ozone_auto_platforms="0" internal_khronos_glcts_tests="1" ozone_platform="gbm"

Once you have a bit of time, could you please do the `ldd` from #1, and the following:

src/$ ninja -C out_link/Debug -t commands flatc

The others are not all that interesting now that I see the same crash stack trace as we had seen before.

All right, I could reproduce the issue myself. Symbol table and DT_NEEDED entries look exactly the same as they did for the *release* build in the other case, even though this is a *debug* build.

$ readelf --dyn-syms out_link/Debug/flatc | grep pthread
    74: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock
    75: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_unlock
   110: 00000000004032b0     0 FUNC    WEAK   DEFAULT  UND __pthread_key_create

$ ldd out_link/Debug/flatc 
	linux-vdso.so.1 =>  (0x00007ffed8ff0000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff325864000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff32549f000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff325199000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff325b68000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff324f83000)

Link step command line:

.../llvm-build/Release+Asserts/bin/clang++ -Wl,-O1 -Wl,-O2 -Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC -fuse-ld=gold -Wl,--disable-new-dtags -o flatc -Wl,--start-group obj.host/third_party/flatbuffers/src/src/flatc.flatc.o obj.host/third_party/flatbuffers/libcompiler_files.a -Wl,--end-group  

Looks like `-pthread` after `-Wl,--as-needed` in there. :-(

OK, turns out the CrOS build environment has an LDFLAGS="-Wl,-O1 -Wl,-O2 -Wl,--as-needed" override, which sets "--as-needed" unexpectedly for debug builds as well, which do not have the fix.

As a workaround, you can just clear that envvar once you are in.

TL;DR: In debug builds, Chromium GYP files never set the `-Wl,--as-needed` option (except on Android), but obviously we still build with `-pthread`. Consequently, we resolved  Issue 623236  by overlinking only in release builds.

Problem is, the Chrome OS build environment sets an LDFLAGS override to "-Wl,-O1 -Wl,-O2 -Wl,--as-needed" indiscriminately, which once again leads to the bogus pseudo-PLT entries in the flatc compiler, and SEGFAULT during Debug GYP build.

1.) Now that GYP is deprecated, do we care anymore?
2.) If yes, should we fix this in Chromium code (by overlinking in debug mode as well), or in `cros chrome-sdk`?
3.) If the latter, where does the code live that sets up the environment?

Why does this bug have Restrict-View-Google applied? Not seeing the reason. Did I miss something?

I don't see a reason either. Removing label.

Also, is this bug still an issue? Did ChromeOS move off of GYP?

GYP is no longer officially supported, and no sheriff (or anyone else) complained of this failing in practice anymore, so I'll go ahead and mark this as obsolete.