Compiler definition for "timersub"

[kahilah]

Problem: When generating libraries via python utilities (libgen or implicitly via pywrap) utility, a warning "implicit declaration of function ‘timersub’" is generated. In addition, when using the produced pyjac_c - library will yield an error "undefined symbol: timersub"

This error appears due to different POSIX vs. BSD definitions (see https://stackoverflow.com/questions/33107237/implicit-declaration-of-timersub-function-in-linux-what-must-i-define?rq=1)

Apparently this is tried to be taken into account in kernel_utils/common/timer.c by #ifndef __USE_BSD #define __USE_BSD but this was not effective on my machine. I also tried #define _BSD_SOURCE unsuccessfully.

Proposed solution: I modified pyjac/libgen/libgen.py file and variable shared_flags to include '-D_BSD_SOURCE' which compiled succesfully.

In particular on line 51: shared_flags = dict(c=['-fPIC', '-D_BSD_SOURCE']

my system: Ubuntu 16.04 gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 python 3.6.6

[skyreflectedinmirrors]

@kahilah interesting... as an educated guess, this is the same machine you have issues with the Conda-version of Adept on? I only have a single server that runs into this issue, and it also has the conda/adept issue.

Anyways, the solution is easier than making edits in the code itself, you can simply modify your siteconf.py to include:

CC_FLAGS = ['-D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809']

The site-conf is a neat trick I stole from pyopencl, which essentially allows the user to specify compiler/link-line options w/o editing the code itself (which again, needs documentation!)
Let me know if you run into any further issues w/ this. I'm planning on ditching timer-sub for a c++ timer soon anyways to a) get around this issue (generally, use more standard library parts), and b) possibly get higher resolutions

In addition, would you mind sharing the output of lscpu and ldd --version? I'm wondering if we can track down the reason the conda-distributed Adept doesn't work via our two configurations, mine is:

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 24 On-line CPU(s) list: 0-23 Thread(s) per core: 2 Core(s) per socket: 6 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 44 Model name: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz Stepping: 2 CPU MHz: 1596.000 CPU max MHz: 2661.0000 CPU min MHz: 1596.0000 BogoMIPS: 5319.89 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 12288K NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb kaiser tpr_shadow vnmi flexpriority ept vpid dtherm ida arat

ldd --version ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.

[kahilah]

Ahh, true and neat...

Yes, this is the same machine. Below the lscpu and ldd outputs. Btw, I managed to successfully reproduce the cantera comparison you provided last week. Soon I test this in OF.

lscpu: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 60 Model name: Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz Stepping: 3 CPU MHz: 1019.484 CPU max MHz: 3700.0000 CPU min MHz: 800.0000 BogoMIPS: 5387.48 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 6144K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts flush_l1d

ldd --version ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper.

[skyreflectedinmirrors]

Ahhh very interesting. I had thought it was something to do with my machine's lack of vector instructions (I only have like sse-4.2 on that machine) but your box has up to AVX2!

I think it's more likely that the culprit is something to do with the version of glibc:

(Ubuntu GLIBC 2.23-0ubuntu10) 2.23

which both machines share. My other machines where Conda Adept works actually have older glibc's (well, possibly? they're GNU versions so it's hard to directly compare them):

(GNU libc) 2.17 (GNU libc) 2.12

^ both are redhat boxes. Good thing to learn!

[skyreflectedinmirrors]

@kahilah one more thing, could you check the version of glibc++? (see here for instructions)

On my failing box:

GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_3.4.21 GLIBCXX_DEBUG_MESSAGE_LENGTH

and on a working box:

GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH

[kahilah]

Good news, my openfoam+spyjac combination works and runs finally :)

So my GLIBCXX match the ones you have failing as well:

3.4
3.4.1
3.4.2
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.4.9
3.4.10
3.4.11
3.4.13
3.4.14
3.4.15
3.4.16
3.4.17
3.4.18
3.4.19
3.4.20
3.4.21