9.4.rc2, dochtml failed if configured with CC=clang and CXX=clang++ (gcc was used sometimes?)

Kazuyoshi Furutaka

unread,

Aug 16, 2021, 7:15:11 PM8/16/21

to sage-devel

Dear sage experts...

I'm sorry again for not showing the fix and only to report....

As the subject says, when configured with CC=clang and CXX=clang++, the build of dochtml failed.

> ***************************************************************
> Error building Sage.
>
> The following package(s) may have failed to build (not necessarily during this run of 'make all-start'):
>
> * documentation: dochtml
> last build time: Aug 13 11:37
> log file: /home/furutaka/work/sage/sage-9.4.rc2-git-clang/logs/pkgs/../dochtml.log

Looking at the log file, ImportError occured many times.

> $ grep ImportError /home/furutaka/work/sage/sage-9.4.rc2-git-clang/logs/pkgs/../dochtml.log | sort | uniq
> [combinat ] ImportError: /home/furutaka/work/sage/sage-9.4.rc2-git-clang/local/lib64/python3.9/site-packages/sage/geometry/polyhedron/combinatorial_polyhedron/face_iterator.cpython-39-x86_64-linux-gnu.so: undefined symbol: __kmpc_end_critical

Then, I searched `face_iterator.cpython-39' in the log of entire make, and found that gcc was used to build the shared object even though it was configured with CC=clang...

> [sagelib-9.4.rc2] gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-rpath-link,/home/furutaka/work/sage/sage-9.4.rc2-git-clang/local/lib -L/home/furutaka/work/sage/sage-9.4.rc2-git-clang/local/lib -Wl,-rpath,/home/furutaka/work/sage/sage-9.4.rc2-git-clang/local/lib -O2 -g -march=native build/temp.linux-x86_64-3.9/build/cythonized/sage/geometry/polyhedron/combinatorial_polyhedron/face_iterator.o -L/usr/lib64 -lgmp -o build/lib.linux-x86_64-3.9/sage/geometry/polyhedron/combinatorial_polyhedron/face_iterator.cpython-39-x86_64-linux-gnu.so -fopenmp -lpari

Searching for the use of "gcc" in the log file, it seems that gcc was used to build the folloiwng packages.

> $ awk '$2=="gcc"{print $1}' make.log | sort | uniq
> [cypari-2.1.2]
> [cysignals-1.10.3]
> [cython-0.29.21]
> [gmpy2-2.1.0b5]
> [markupsafe-1.1.1]
> [matplotlib-3.3.4]
> [memory_allocator-0.1.0]
> [numpy-1.20.3]
> [pillow-8.1.2]
> [psutil-5.2.0.p2]
> [pyzmq-22.0.3]
> [sagelib-9.4.rc2]
> [scipy-1.6.3]
> [singular-4.2.0p3]
> [tornado-6.0.4]

Is the use of gcc normal/correct/intended when CC=clang?

Thanks.

Kazuyoshi

Dima Pasechnik

unread,

Aug 16, 2021, 11:41:13 PM8/16/21

to sage-devel

How exactly do you call ./configure?

CC=clang CXX=clang++ ./configure <more options>

produces a working build on some systems at least.

In principle, gcc and clang are producing compatible binaries, but YMMV.

Not so for g++ and clang++, mixing them up is likely to fail. There's also an extra complication involving clang's libc++ (its use depends upon your configuration)

vs gcc's libstdc++

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/08763baa-fa57-4c4f-b190-86bec21b1231n%40googlegroups.com.

Kazuyoshi Furutaka

unread,

Aug 16, 2021, 11:50:24 PM8/16/21

to sage-...@googlegroups.com

2021年8月17日(火) 12:41 Dima Pasechnik <dim...@gmail.com>:

How exactly do you call ./configure?

CC=clang CXX=clang++ ./configure <more options>

produces a working build on some systems at least.

In principle, gcc and clang are producing compatible binaries, but YMMV.

Not so for g++ and clang++, mixing them up is likely to fail. There's also an extra complication involving clang's libc++ (its use depends upon your configuration)
vs gcc's libstdc++

I did: `./configure CC=clang CXX=clang++`

Kazuyoshi

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/7-WLor8-71c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0HOHqr5AVA_nd44sbN6QGr25bij1RfWYZAhkSsLjn-dQ%40mail.gmail.com.

--

Kazuyoshi Furutaka

Dima Pasechnik

unread,

Aug 17, 2021, 12:28:28 AM8/17/21

to sage-devel

On Tue, 17 Aug 2021, 06:50 Kazuyoshi Furutaka, <furutaka....@gmail.com> wrote:

2021年8月17日(火) 12:41 Dima Pasechnik <dim...@gmail.com>:
How exactly do you call ./configure?

CC=clang CXX=clang++ ./configure <more options>

produces a working build on some systems at least.

In principle, gcc and clang are producing compatible binaries, but YMMV.

Not so for g++ and clang++, mixing them up is likely to fail. There's also an extra complication involving clang's libc++ (its use depends upon your configuration)
vs gcc's libstdc++

I did: `./configure CC=clang CXX=clang++`

please try the way I suggest, hopefully it will work better.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANjERvegMthnw0fVCY6EAhbA5JJNepgLvpoGZ5re2cy06m7thQ%40mail.gmail.com.

Kazuyoshi Furutaka

unread,

Aug 17, 2021, 12:42:20 AM8/17/21

to sage-devel

2021年8月17日火曜日 13:28:28 UTC+9 dim...@gmail.com:

On Tue, 17 Aug 2021, 06:50 Kazuyoshi Furutaka, <furutaka....@gmail.com> wrote:

2021年8月17日(火) 12:41 Dima Pasechnik <dim...@gmail.com>:
How exactly do you call ./configure?

CC=clang CXX=clang++ ./configure <more options>

produces a working build on some systems at least.

In principle, gcc and clang are producing compatible binaries, but YMMV.

Not so for g++ and clang++, mixing them up is likely to fail. There's also an extra complication involving clang's libc++ (its use depends upon your configuration)
vs gcc's libstdc++

I did: `./configure CC=clang CXX=clang++`

please try the way I suggest, hopefully it will work better.

Now trying: at least partially gcc was used until now...

> awk '$2=="gcc"{print $1}' make.log|uniq
>[cython-0.29.21]
>[cysignals-1.10.3]
>[cypari-2.1.2]

Kazuyoshi Furutaka

unread,

Aug 17, 2021, 3:46:33 AM8/17/21

to sage-devel

2021年8月17日火曜日 13:42:20 UTC+9 Kazuyoshi Furutaka:

The build failed with the same error (ImportError in building dochtml).

Error building Sage.

The following package(s) may have failed to build (not necessarily
during this run of 'make all-start'):

* documentation: dochtml

last build time: Aug 17 16:12
log file: /home/furutaka/work/sage/sage-9.4.rc2-git-clang2/logs/pkgs/../dochtml.log

$ awk '$2=="gcc"{print $1}' make.log | sort | uniq
[cypari-2.1.2]
[cysignals-1.10.3]
[cython-0.29.21]
[gmpy2-2.1.0b5]
[markupsafe-1.1.1]
[matplotlib-3.3.4]
[memory_allocator-0.1.0]
[numpy-1.20.3]
[pillow-8.1.2]
[psutil-5.2.0.p2]
[pyzmq-22.0.3]
[sagelib-9.4.rc2]
[scipy-1.6.3]
[singular-4.2.0p3]
[tornado-6.0.4]

$ awk '$2=="gcc"{print}' make.log | uniq | head -3
[cython-0.29.21]   gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-rpath-link,/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -L/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -Wl,-rpath,/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -O2 -g -march=native build/temp.linux-x86_64-3.9/tmp/pip-req-build-8u5zovrq/Cython/Plex/Scanners.o -L/usr/lib64 -o build/lib.linux-x86_64-3.9/Cython/Plex/Scanners.cpython-39-x86_64-linux-gnu.so
[cython-0.29.21]   gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-rpath-link,/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -L/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -Wl,-rpath,/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -O2 -g -march=native build/temp.linux-x86_64-3.9/tmp/pip-req-build-8u5zovrq/Cython/Plex/Actions.o -L/usr/lib64 -o build/lib.linux-x86_64-3.9/Cython/Plex/Actions.cpython-39-x86_64-linux-gnu.so
[cython-0.29.21]   gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-rpath-link,/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -L/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -Wl,-rpath,/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/local/lib -O2 -g -march=native build/temp.linux-x86_64-3.9/tmp/pip-req-build-8u5zovrq/Cython/Compiler/Scanning.o -L/usr/lib64 -o build/lib.linux-x86_64-3.9/Cython/Compiler/Scanning.cpython-39-x86_64-linux-gnu.so

Isuru Fernando

unread,

Aug 17, 2021, 4:05:31 AM8/17/21

to sage-devel

Did you rebuild python? You might have to do "make distclean".

Isuru

Kazuyoshi Furutaka

unread,

Aug 17, 2021, 4:22:09 AM8/17/21

to sage-...@googlegroups.com

2021年8月17日(火) 17:05 Isuru Fernando <isu...@gmail.com>:

Did you rebuild python? You might have to do "make distclean".

Isuru

I believe I didn't.

excerpt from the config.log...

4360 ## -------------------------------------------------------- ##
4361 ## Checking whether SageMath should install SPKG python3... ##
4362 ## -------------------------------------------------------- ##
4363 configure:33651: checking whether any of bzip2 xz libffi is installed as or will be installed as SPKG
4364 configure:33660: result: no
4365 configure:33664: checking for python3 >= 3.7.0, < 3.10.0 with modules sqlite3, ctypes, math, hashlib, crypt, socket, zlib, distutils.core
4366 configure:34331: result:
4367 configure:34355: checking ... whether /usr/bin/python3 is good
4368 CC=clang CXX=clang++ -std=gnu++11 conftest_venv/bin/python3 conftest.py --verbose build --build-base=conftest.dir
4369 running build
4370 running build_ext
4371 building 'config_check_distutils' extension
4372 creating conftest.dir
4373 creating conftest.dir/temp.linux-x86_64-3.9
4374 clang -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOU
4374 RCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O
4374 2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic -fasyn
4374 chronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_
4374 FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC
4374 -fwrapv -Dlinux -I/usr/include -fPIC -I/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/conftest_venv/include -I/usr/include/python3.9 -c conftest.c -o conftest.dir/temp.linux-
4374 x86_64-3.9/conftest.o
4375 creating conftest.dir/lib.linux-x86_64-3.9
4376 gcc -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Dlinux -I/usr/include conftest.dir/temp.linux-x86_64-3.9/conftest.o -
4376 L/usr/lib64 -o conftest.dir/lib.linux-x86_64-3.9/config_check_distutils.cpython-39-x86_64-linux-gnu.so
4377 CC=clang CXX=clang++ -std=gnu++11 conftest_venv/bin/python3 conftest.py --verbose build --build-base=conftest.dir
4378 running build
4379 running build_ext
4380 building 'config_check_distutils_cxx' extension
4381 creating conftest.dir
4382 creating conftest.dir/temp.linux-x86_64-3.9
4383 clang -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOU
4383 RCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O
4383 2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic -fasyn
4383 chronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_
4383 FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC
4383 -fwrapv -Dlinux -I/usr/include -fPIC -I/home/furutaka/work/sage/sage-9.4.rc2-git-clang2/conftest_venv/include -I/usr/include/python3.9 -c conftest.cpp -o conftest.dir/temp.linu
4383 x-x86_64-3.9/conftest.o -std=c++11
4384 creating conftest.dir/lib.linux-x86_64-3.9
4385 clang++ -pthread -shared -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -g -Dlinux -I/usr/include conftest.dir/temp.linux-x86_64-3.9/conftest 4385 .o -L/usr/lib64 -o conftest.dir/lib.linux-x86_64-3.9/config_check_distutils_cxx.cpython-39-x86_64-linux-gnu.so
4386 configure:34909: result: yes
4387 configure:34911: checking for python3 >= 3.7.0, < 3.10.0 with modules sqlite3, ctypes, math, hashlib, crypt, socket, zlib, distutils.core
4388 configure:34977: result: /usr/bin/python3
4389 configure:34994: will use system package and not install SPKG python3

What I did was:

`git checkout -b <a_tagged_version>`
rsync to a separate directory for building,
`make configure`
`CC=clang CXX=clang++ ./configure`
`./config.status recheck && ./config.status`
`script -c make make.log`

By the way I forgot to mention but it's on a linux running fedora-34 (x86_64).

Kazuyoshi

--

Kazuyoshi Furutaka

Isuru Fernando

unread,

Aug 17, 2021, 4:35:47 AM8/17/21

to sage-devel

Ah, you are using the system python that was built with gcc, but you want to build sage with clang/clang++.

In python, setting CC will override the compiler used for building extension modules, but

it will not override the linker used for building an extension module.

What happens here is a file is compiled with `-fopenmp` with clang (meaning it needs to be linked with libomp from LLVM),

but linked with `-fopenmp` with gcc (meaning it links to libgomp from GNU).

To fix this, you'll have to set env variable LDSHARED="clang -pthread -shared"

Isuru Fernando

--

You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANjERveCGS%2Bcqv9yBpDXsAatUw7qBUt3WU4JSqbUEvG2_d%2Bt-A%40mail.gmail.com.

Kazuyoshi Furutaka

unread,

Aug 17, 2021, 4:49:15 AM8/17/21

to sage-devel

2021年8月17日火曜日 17:35:47 UTC+9 isu...@gmail.com:

Ah, you are using the system python that was built with gcc, but you want to build sage with clang/clang++.

In python, setting CC will override the compiler used for building extension modules, but
it will not override the linker used for building an extension module.

What happens here is a file is compiled with `-fopenmp` with clang (meaning it needs to be linked with libomp from LLVM),
but linked with `-fopenmp` with gcc (meaning it links to libgomp from GNU).

To fix this, you'll have to set env variable LDSHARED="clang -pthread -shared"

Thanks. I'll give it a try.

The reason I build recent sage with clang[,++] (in addition to a separate build with gcc) is because the build with gcc failed in building older gcc (10.x?) on recent fedora (with gcc 11).

To add one thing, the dochtml build error occurs only on recent sage (& fedora) versions...

Kazuyoshi

Dima Pasechnik

unread,

Aug 17, 2021, 4:55:05 AM8/17/21

to sage-devel

Most probably, a system Python is used.

We need the top-level config.log to know for sure.

It used to work for me on Fedora 32 with system Python

On Tue, 17 Aug 2021, 11:05 Isuru Fernando, <isu...@gmail.com> wrote:

Did you rebuild python? You might have to do "make distclean".

Isuru

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voNa5nPkB5LHe_%3DYdEnWWYWvjpx5NH5iE%3DvFvB8%3DE%2BWkaw%40mail.gmail.com.

Kazuyoshi Furutaka

unread,

Aug 17, 2021, 5:10:11 AM8/17/21

to sage-devel

2021年8月17日火曜日 17:55:05 UTC+9 dim...@gmail.com:

Most probably, a system Python is used.
We need the top-level config.log to know for sure.

It used to work for me on Fedora 32 with system Python

On Tue, 17 Aug 2021, 11:05 Isuru Fernando, <isu...@gmail.com> wrote:
Did you rebuild python? You might have to do "make distclean".

Isuru

I'll attach the top-level config.log after `./config.status --recheck && ./config.status` following `CC=clang CXX=clang++ ./configure`.

Kazuyoshi

config.log

Dima Pasechnik

unread,

Aug 17, 2021, 5:35:35 AM8/17/21

to sage-devel

On Tue, 17 Aug 2021, 11:35 Isuru Fernando, <isu...@gmail.com> wrote:

Ah, you are using the system python that was built with gcc, but you want to build sage with clang/clang++.

In python, setting CC will override the compiler used for building extension modules, but
it will not override the linker used for building an extension module.

What happens here is a file is compiled with `-fopenmp` with clang (meaning it needs to be linked with libomp from LLVM),
but linked with `-fopenmp` with gcc (meaning it links to libgomp from GNU).

To fix this, you'll have to set env variable LDSHARED="clang -pthread -shared"

Thanks, great catch - perhaps we should have this in docs or wiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voMt4--cAM%2BUKSQaVz2GGPMb3w%3D_tfnY-pfdJ4AiNZmzQA%40mail.gmail.com.

Kazuyoshi Furutaka

unread,

Aug 17, 2021, 9:54:19 AM8/17/21

to sage-devel

2021年8月17日火曜日 18:35:35 UTC+9 dim...@gmail.com:

On Tue, 17 Aug 2021, 11:35 Isuru Fernando, <isu...@gmail.com> wrote:
Ah, you are using the system python that was built with gcc, but you want to build sage with clang/clang++.

In python, setting CC will override the compiler used for building extension modules, but
it will not override the linker used for building an extension module.

What happens here is a file is compiled with `-fopenmp` with clang (meaning it needs to be linked with libomp from LLVM),
but linked with `-fopenmp` with gcc (meaning it links to libgomp from GNU).

To fix this, you'll have to set env variable LDSHARED="clang -pthread -shared"

Thanks, great catch - perhaps we should have this in docs or wiki.

Then I did two builds.

The first:

$ CC=clang CXX=clang++ LDSHARED="clang -pthread -shared" ./configure && CC=clang CXX=clang++ LDSHARED="clang -pthread -shared" ./config.status --recheck && CC=clang CXX=clang++ LDSHARED="clang -pthread -shared" ./config.status && LDSHARED="clang -pthread -shared" make

-> Error building Sage.

The following package(s) may have failed to build (not necessarily
during this run of 'make all-start'):

* documentation: dochtml

last build time: Aug 17 19:22
log file: /home/furutaka/work/sage/sage-9.4.rc2-git-clang3/logs/pkgs/../dochtml.log

The second:

$ CC=clang CXX=clang++ ./configure --with-system-python3=no && CC=clang CXX=clang++ ./config.status --recheck && CC=clang CXX=clang++ ./config.status && make

-> build finished without errors.

Reply all

Reply to author

Forward