From: mvf <mvf@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: blender: enable alembic support
Date: Fri, 10 Jul 2020 08:28:35 +0200 [thread overview]
Message-ID: <20200710062835.WUxx9shN3_Q8Ne0RDUPTqPO_skUIZztiQDOSg_7fefE@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-23498@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]
New comment by mvf on void-packages repository
https://github.com/void-linux/void-packages/pull/23498#issuecomment-656507808
Comment:
**TL;DR**
- the TR1 flavor of `alembic` is useless
- `libatomic` is required on `armv6l*`
**Prose**
> what's up with that tr1 change
TR1 is an obsolete non-standard C++ extension that has been effectively superseded by C++11. `alembic`'s TR1 build option is merely a fallback for people stuck on GCC < 4.8. Enabling it changes `alembic`'s interfaces, making it useless on modern systems. That's also why a build option makes no sense. From the README:
```
Some examples of OPTIONS you may want or need to use include:
[...]
-DALEMBIC_LIB_USES_TR1=ON or -DALEMBIC_LIB_USES_BOOST=ON if you do not have
a C++11 capable compiler specify one of these to use TR1, or boost as
a dependency of the Alembic library.
```
My guess is that the original `alembic` packager wasn't a C++ person and thought enabling TR1 was a neat way to get it to link without patching. From `lib/Alembic/CMakeLists.txt`:
```cmake
# link in atomic if we are using tr1 and the compiler is new enough
# to want __atomic_compare_exchange_n
IF ( ${ALEMBIC_LIB_USES_TR1} AND CMAKE_COMPILER_IS_GNUCXX AND
CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 4.8 )
TARGET_LINK_LIBRARIES( Alembic atomic )
ENDIF()
```
> without tr1, atomic shouldn't be necessary at all
`armv6l*` disagrees:
```
/usr/lib/gcc/arm-linux-gnueabihf/9.3.0/../../../../arm-linux-gnueabihf/bin/ld: ../../libAlembic.so.1.7.12: undefined reference to `__atomic_fetch_or_8'
/usr/lib/gcc/arm-linux-gnueabihf/9.3.0/../../../../arm-linux-gnueabihf/bin/ld: ../../libAlembic.so.1.7.12: undefined reference to `__atomic_compare_exchange_8'
/usr/lib/gcc/arm-linux-gnueabihf/9.3.0/../../../../arm-linux-gnueabihf/bin/ld: ../../libAlembic.so.1.7.12: undefined reference to `__atomic_load_8'
/usr/lib/gcc/arm-linux-gnueabihf/9.3.0/../../../../arm-linux-gnueabihf/bin/ld: ../../libAlembic.so.1.7.12: undefined reference to `__atomic_store_8'
```
next prev parent reply other threads:[~2020-07-10 6:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-09 17:44 [PR PATCH] " mvf
2020-07-09 23:44 ` fosslinux
2020-07-10 1:09 ` q66
2020-07-10 1:09 ` q66
2020-07-10 6:24 ` [PR PATCH] [Updated] " mvf
2020-07-10 6:28 ` mvf [this message]
2020-07-10 7:16 ` blender: update to 2.83.2, " mvf
2020-07-10 10:57 ` fosslinux
2020-07-10 10:57 ` fosslinux
2020-07-10 13:03 ` q66
2020-07-10 15:57 ` mvf
2020-07-10 17:55 ` q66
2020-07-23 18:19 ` [PR PATCH] [Updated] " mvf
2020-07-24 5:16 ` blender: update to 2.83.3, " mvf
2020-07-24 5:25 ` Gottox
2020-07-24 5:25 ` [PR PATCH] [Merged]: " Gottox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200710062835.WUxx9shN3_Q8Ne0RDUPTqPO_skUIZztiQDOSg_7fefE@z \
--to=mvf@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).