Tom Lane <[email protected]> writes:
> Replace random(), pg_erand48(), etc with a better PRNG API and algorithm.
Hmm, fairywren doesn't like this [1]:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3
-Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g
-O2 win32ver.o pg_test_fsync.o -L../../../src/port -L../../../src/common
-Wl,--allow-multiple-definition -Wl,--disable-auto-import -L/c/prog/3p64/lib
-L/c/prog/3p64/openssl/lib -Wl,--as-needed -lpgcommon -lpgport -lssl -lcrypto
-lz -lws2_32 -lm -lws2_32 -o pg_test_fsync.exe
C:/tools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
pg_test_fsync.o: in function `main':
C:/tools/msys64/home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/bin/pg_test_fsync/pg_test_fsync.c:121:
undefined reference to `__imp_pg_global_prng_state'
collect2.exe: error: ld returned 1 exit status
I think what is going on here is that the compilation of pg_test_fsync.c
sees
extern PGDLLIMPORT pg_prng_state pg_global_prng_state;
and does something that's inappropriate when the variable is actually
coming from elsewhere in the same program. If so, we could perhaps
fix it by doing
#ifdef FRONTEND
extern pg_prng_state pg_global_prng_state;
#else
extern PGDLLIMPORT pg_prng_state pg_global_prng_state;
#endif
Thoughts?
regards, tom lane
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2021-11-29%2003%3A04%3A24
