Undefined symbols "pstring_t<putf8_traits>::operator=(pstring_t<putf8_traits>&&)"

[ryandesign]

Hello,

I am a MacPorts developer, and I was just trying to update our mame port to a newer version, but the newest I was able to update to was 0.206. 0.207 and later versions up to the latest at this time, 0.216, failed to build for me as follows:

Undefined symbols for architecture x86_64:
  "pstring_t<putf8_traits>::operator=(pstring_t<putf8_traits>&&)", referenced from:
      netlist_mame_stream_input_device::custom_netlist_additions(netlist::netlist_state_t&) in liboptional.a(netlist.o)
      plib::pfmt& plib::pfmt::format_element<char const*>(char32_t, char const*&&) in liboptional.a(netlist.o)
      std::__1::vector<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >, std::__1::allocator<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > > > >::insert(std::__1::__wrap_iter<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > > const*>, std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >&&) in liboptional.a(netlist.o)
      std::__1::vector<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >, std::__1::allocator<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > > > >::__move_range(std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >*, std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >*, std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >*) in liboptional.a(netlist.o)
      std::__1::__split_buffer<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >, std::__1::allocator<std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > > >&>::push_back(std::__1::pair<pstring_t<putf8_traits>, plib::owned_ptr<netlist::core_device_t, plib::arena_deleter<plib::mempool, netlist::core_device_t> > >&&) in liboptional.a(netlist.o)
      plib::pfmt& plib::pfmt::format_element<unsigned int const&>(char32_t, unsigned int const&&&) in liboptional.a(netlist.o)
      plib::pfmt& plib::pfmt::format_element<unsigned long const&>(char32_t, unsigned long const&&&) in liboptional.a(netlist.o)
      ...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../../../../../mame64] Error 1
make[1]: *** [mame] Error 2

This was on macOS 10.13.6 with Xcode 9.4.1. The clang version is:

$ clang -v
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I was passing these arguments to make:

ARCHOPTS="-Os -stdlib=libc++" \
CC="/usr/bin/clang" \
CXX="/usr/bin/clang++" \
LDOPTS="-L/opt/local/lib -lSDL2" \
NOWERROR=1 \
USE_LIBSDL=1 \
USE_SYSTEM_LIB_ASIO=1 \
USE_SYSTEM_LIB_EXPAT=1 \
USE_SYSTEM_LIB_FLAC=1 \
USE_SYSTEM_LIB_JPEG=1 \
USE_SYSTEM_LIB_LUA=1 \
USE_SYSTEM_LIB_PORTAUDIO=1 \
USE_SYSTEM_LIB_PORTMIDI=1 \
USE_SYSTEK_LIB_PUGIXML=1 \
USE_SYSTEM_LIB_SQLITE3=1 \
USE_SYSTEM_LIB_UTF8PROC=1 \
USE_SYSTEM_LIB_ZLIB=1 \
VERBOSE=1 

[couriersud]

Looks like a compiler issue. pstring<..> operator= is a default operator (pstring.h:130):
pstring_t &operator=(pstring_t &&string) noexcept = default;
pstring<..> is defined as an extern (line 481)
extern template struct pstring_t<putf8_traits>;
and implemented in pstring.cpp(line 89):

You may try to rewirte pstring.h(130) to read
pstring_t &operator=(pstring_t &&string) noexcept : m_str(std::move(string.m_str)) {}
and try if this works.

[couriersud]

@ryandesign: Any news on this?

[couriersud]

Closing this. Assume fixed.

[ryandesign]

Closing this. Assume fixed.

Not fixed. Please reopen. I am not able to build any version after 0.206 on macOS. My lack of response to an issue does not mean it is fixed.

You may try to rewirte pstring.h(130) to read
pstring_t &operator=(pstring_t &&string) noexcept : m_str(std::move(string.m_str)) {}
and try if this works.

When I make this change, the error is:

In file included from ../../../../../src/mame/drivers/aleisttl.cpp:30:
In file included from ../../../../../src/devices/machine/netlist.h:17:
In file included from ../../../../../src/devices/machine/../../lib/netlist/nltypes.h:15:
In file included from ../../../../../src/devices/machine/../../lib/netlist/nl_config.h:11:
In file included from ../../../../../src/devices/machine/../../lib/netlist/plib/pexception.h:11:
../../../../../src/devices/machine/../../lib/netlist/plib/pstring.h:144:52: error: only constructors take base initializers
        pstring_t &operator=(pstring_t &&string) noexcept : m_str(std::move(string.m_str)) {}
                                                          ^
In file included from ../../../../../src/mame/drivers/aleisttl.cpp:30:
In file included from ../../../../../src/devices/machine/netlist.h:17:
In file included from ../../../../../src/devices/machine/../../lib/netlist/nltypes.h:17:
In file included from ../../../../../src/devices/machine/../../lib/netlist/plib/pmempool.h:13:
../../../../../src/devices/machine/../../lib/netlist/plib/pstream.h:180:44: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                std::array<std::istream::char_type, 4> b{0};
                                                         ^
                                                         {}
In file included from ../../../../../src/mame/drivers/aleisttl.cpp:1:
In file included from ../../../../../src/emu/emu.h:59:
/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk-new_emulators_mame/mame/work/mame-mame0226/build/projects/sdl/mame/gmake-osx-clang/../../../../../src/emu/input.h:472:92: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        template <size_t... N> input_seq(std::integer_sequence<size_t, N...>) noexcept : m_code({ get_end_code(N)... }) { }
                                                                                                  ^~~~~~~~~~~~~~~
                                                                                                  {              }
/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk-new_emulators_mame/mame/work/mame-mame0226/build/projects/sdl/mame/gmake-osx-clang/../../../../../src/emu/input.h:430:25: note: in instantiation of function template specialization 'input_seq::input_seq<0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15>' requested here
        input_seq() noexcept : input_seq(std::make_index_sequence<std::tuple_size<decltype(m_code)>::value>()) { }
                               ^
2 warnings and 1 error generated.

[rb6502]

I don't know what to tell you. Every version of MAME this year up to and including the latest builds fine on macOS when done according to our build instructions (SDL2 installed as a framework and using our built-in versions of the 3rd party libraries). I don't think the USE_SYSTEM_LIB stuff should make a difference there (it's fine on Linux AFAIK), but it certainly seems to.

[cuavas]

This is not reproducible by any of our regular macOS developers, or when using clang on Linux. The template instantiations come after all the bodies are available. Your suggested change is syntactically invalid. It must be an issue with your environment.

[mascguy]

This is not reproducible by any of our regular macOS developers, or when using clang on Linux. The template instantiations come after all the bodies are available. Your suggested change is syntactically invalid. It must be an issue with your environment.

Can you folks confirm that Mame builds successfully under MacOS 10.13 through 10.15? I ask, as I'd like to assist Ryan with resolving this issue.

Also, can you provide the Xcode versions you're building with, for each of those three MacOS releases?

[rb6502]

I can verify that every MAME release for at least the last 7 years built fine on the currently available macOS and Xcode version when it was released. I'm not set up to go all the way back to 10.13 right now, but the last release version should be fine that far back.

[mascguy]

I can verify that every MAME release for at least the last 7 years built fine on the currently available macOS and Xcode version when it was released. I'm not set up to go all the way back to 10.13 right now, but the last release version should be fine that far back.

Thank you for the confirmation!

Thus far, I've been able to successfully build and run release 0.226, via MacPorts, on both MacOS 10.13 and 10.14. (And the 10.15 build is currently in-progress.)

I'll reach out to Ryan privately, relative to his build issues. Thanks again for the reply!

[rb6502]

Thanks, I appreciate it!

[startaq]

FWIW the CI uses macOS 10.15 currently. Example build log: https://github.com/mamedev/mame/runs/1419481415

[mascguy]

As an update, builds also succeed on MacOS 10.15.

However, builds fail on 10.12, with the same link error cited by Ryan.

The following Xcode versions were used:

MacOS Version	Xcode Version
10.12.6	9.1
10.13.6	10.1
10.14.6	11.3.1
10.15.6	12.0

So, I'm wondering if this is an issue with the various Xcode 9.x releases, given that Ryan's build failed too?

[ryandesign]

Thanks, I'm deliberately staying with Xcode 9.4.1 on 10.13.6 because Xcode 10 removes some ability to build 32-bit software. But I was able to build mame 0.226 on 10.13.6 using a newer open source clang 9.0.1 compiler from MacPorts. So perhaps something that was added/changed in mame 0.207 is incompatible with Apple clang versions prior to Xcode 10's.

[galibert]

Note that current and future master versions require c++17 which require reasonably recent versions of clang and hence xcode. OG.

…

On Sun, Nov 22, 2020 at 2:44 PM Ryan Schmidt ***@***.***> wrote: Thanks, I'm deliberately staying with Xcode 9.4.1 on 10.13.6 because Xcode 10 removes some ability to build 32-bit software. But I was able to build mame 0.226 on 10.13.6 using a newer open source clang 9.0.1 compiler from MacPorts. So perhaps something that was added/changed in mame 0.207 is incompatible with Apple clang versions prior to Xcode 10's. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6004 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGSF4IJFZJVWQ2L3OVABLLSREITJANCNFSM4JT2A6HQ> .

[mascguy]

We've encountered one more build issue, related to language translations: Portuguese_Brazil is failing, with the following errors from 'msgmerge':

language/Portuguese_Brazil/strings.po:1693:19: invalid control sequence
language/Portuguese_Brazil/strings.po:3024: end-of-line within string
language/Portuguese_Brazil/strings.po:3024: keyword "come" unknown
language/Portuguese_Brazil/strings.po:3024:5: syntax error
language/Portuguese_Brazil/strings.po:3024: keyword "a" unknown
language/Portuguese_Brazil/strings.po:3024: keyword "com" unknown
language/Portuguese_Brazil/strings.po:3024: keyword "algo" unknown
language/Portuguese_Brazil/strings.po:3024: keyword "mas" unknown
language/Portuguese_Brazil/strings.po:3024: keyword "o" unknown
language/Portuguese_Brazil/strings.po:3024: keyword "perde" unknown
language/Portuguese_Brazil/strings.po:3025: end-of-line within string
language/Portuguese_Brazil/strings.po:3031: end-of-line within string
language/Portuguese_Brazil/strings.po:3031: keyword "sem" unknown
language/Portuguese_Brazil/strings.po:3031:4: syntax error
language/Portuguese_Brazil/strings.po:3031: keyword "um" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "item" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "e" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "depois" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "voc" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "o" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "consegue" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "por" unknown
language/Portuguese_Brazil/strings.po:3031: keyword "exemplo" unknown
language/Portuguese_Brazil/strings.po:3032: end-of-line within string
msgmerge: found 24 fatal errors

The lines in question are:

[...]
msgstr "Cab. Mag.\Imperfeito\n"
[...]
msgstr "Use isto se quiser fazer um poke o Slot 1 (Quando você
começa com algo mas o perde)"
[...]
msgstr "Use isto se quiser fazer um poke com o valor do Último Slot (Quando você começa
sem um item e depois você o consegue por exemplo)"
[...]

The first message appears to be missing a 't', immediately following the first backslash. While the latter two messages appear to be split across lines, without an appropriate leading and trailing double quote per-line.

Changing those as follows, fixes the issue:

[...]
msgstr "Cab. Mag.\tImperfeito\n"
[...]
msgstr "Use isto se quiser fazer um poke o Slot 1 (Quando você "
"começa com algo mas o perde)"
[...]
msgstr "Use isto se quiser fazer um poke com o valor do Último Slot (Quando você começa "
"sem um item e depois você o consegue por exemplo)"
[...]

I'm a bit rusty with respect to GNU gettext, but... are these legitimate errors?

[cuavas]

Those errors in the .po file should be fixed.

[mascguy]

Those errors in the .po file should be fixed.

Should I open a new issue, or would you folks prefer to?

[cuavas]

You could open a pull request, or wait for someone else to get to it. It’s not related to this issue, anyway.

[mascguy]

I've opened the following new issue, covering the translation error:

Mame 0.226: Translations: Minor Portuguese_Brazil Message Issues #7510

Thanks again for all of your help folks!

[ryandesign]

Note that current and future master versions require c++17 which require reasonably recent versions of clang and hence xcode.

Thanks for the heads up. According to our information, Xcode 9.3 and later (Apple clang 902.0.39.1 and later) support C++17. So that still doesn't explain your apparent requirement of Xcode 10 / Apple Clang 1000.

[rb6502]

The requirement is specifically this:
./../../../../src/lib/netlist/solver/nld_ms_gcr.h:28:8: error: aligned deallocation function of type
'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer
class matrix_solver_GCR_t: public matrix_solver_ext_t<FT, SIZE>

The issue is that the MacPorts Clang compiler uses the system libc++ rather than bringing along the one for that version of LLVM. So you can't get full C++17 support prior to 10.14 for things that are library features rather than language features.

One workaround was discussed here (flat-out replacing the system's libc++) but that's not great.
https://www.mail-archive.com/macports-dev@lists.macports.org/msg07693.html

We may be able to change MAME to get around that particular requirement, I'm not familiar with the details there.

[cuavas]

I really don’t want to have to blacklist any more C++17 features than the ones listed in the announcement. Trying to support GCC 4.9 with its broken C++14 support was more trouble than it was worth. I don’t want to put the team through that again.

[ryandesign]

The issue is that the MacPorts Clang compiler uses the system libc++ rather than bringing along the one for that version of LLVM. So you can't get full C++17 support prior to 10.14 for things that are library features rather than language features.

Ah, ok. In that case, you really do require macOS 10.14 or later from here on out and this issue is moot.

[mascguy]

The issue is that the MacPorts Clang compiler uses the system libc++ rather than bringing along the one for that version of LLVM. So you can't get full C++17 support prior to 10.14 for things that are library features rather than language features.

Ah, ok. In that case, you really do require macOS 10.14 or later from here on out and this issue is moot.

Gosh, it would be disappointing if Mame were now 10.14+ only. Though I certainly respect the need to move forward, and not spend countless hours trying to support older platforms.

That said, if it were easily doable to support 10.12+ (or even 10.13+), that would be my vote.

I haven't dug too deeply into the past discussion yet, but... is there any possibility of using an alternative to libc++, such as Boost? (Assuming the latter provides everything needed, that is...)