legacy support "error: conflicting asm label" when building some ports

[rmottola (Riccardo)]

I am unable to build cmake on Leopard i386 I tried clang 3.9 and 5.0, I get the same output:

In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cmake/cmake/work/cmake-3.14.5/Source/cmLinkedTree.h:8:
In file included from /usr/include/assert.h:44:
/opt/local/include/LegacySupport/stdlib.h:44:14: error: conflicting asm label
extern char *realpath(const char * __restrict, char * __restrict)
             ^
/usr/include/stdlib.h:226:60: note: previous declaration is here
char    *realpath(const char * __restrict, char * __restrict) __DARWIN_EXTSN(realpath);
                                                              ^
/usr/include/sys/cdefs.h:365:36: note: expanded from macro '__DARWIN_EXTSN'
#define __DARWIN_EXTSN(sym)             __asm("_" __STRING(sym) __DARWIN_SUF_EXTSN)
                                              ^
1 error generated.
gmake: *** [Makefile:6: cmAddCustomTargetCommand.o] Error 1
gmake: *** Waiting for unfinished jobs....
1 error generated.
gmake: *** [Makefile:4: cmAddCustomCommandCommand.o] Error 1

I suppose this is more LegacySupport issue than cmake, a redefiition of realpath

[kencu (Ken)]

complicated error...have to think about this one.

[kencu (Ken)]

Data point: Leopard PPC builds cmake 3.14.5 without any trouble.

[rmottola (Riccardo)]

The way to get cmake building (tested on both 32bit and 64bit) is this suggestion (by Ken):

In the portfile in this section:_

if {!((${os.platform} eq "darwin" && ${os.major} < 10) || ${build_arch} eq "ppc" || ${build_arch} eq "ppc64")} {
    depends_lib-append port:libcxx
    configure.cxx_stdlib libc++
}
PortGroup cxx11 1.1

Change os.major from 10 to 9

[rmottola (Riccardo)]

Personal note: why does the suggested fix work? I think it is "wrong" even if it works.

In another bug ​https://trac.macports.org/ticket/58834#ticket, I just suggested (and have proven) that os.major < 10 works on the same computer.

I think it is the "!" part that is confusing and the test is written wrong. It should be used always with Darwin 9.x What is up with ppc? should it be excluded or included from libcxx?

[kencu (Ken)]

Forcing cmake to build with libc++ on Intel on 10.5 works to fix the math error you were having with the libstdc++ headers (that error is not in this ticket). That makes cmake on 10.5 Intel build the same as it does on every other darwin Intel system, and that path is well-trodden and so works. We might figure out how to fix that math error so that gcc7 can build cmake on darwin 10.5 Intel, but life is short, frankly...

The asm error you had at the start of this ticket is something else, and I think may be spurious, as it has not been seen since. I don't understand it just yet.

PPC on MacPorts can't presently use libc++ (I think I have one of the only PPC systems on earth where libc++ works on PPC, and it's not presently for general use). So for now, PPC builds cmake with gcc6 against the libgcc headers (and that works).

[rmottola (Riccardo)]

Possibly the initial error was spurious. I understand that libc++ needs to be excluded, but is fine for intel. Shouldn't it be written like this then, instead of forcing os < 9? Once it will work on PPC and/or PPC64 just remove the later tests

if {(${os.platform} eq "darwin" && ${os.major} < 10) && !(${build_arch} eq "ppc" || ${build_arch} eq "ppc64")} {
    depends_lib-append port:libcxx
    configure.cxx_stdlib libc++
}

[rmottola (Riccardo)]

I confirm my suggestion works on 10.5 x86 - please think about it.

[kencu (Ken)]

Well the way that is written in 58677#comment:8

IF (Darwin) and (darwin < 10) and (NOT PPC) then

Force libc++

That approach will only work on an intel machine running darwin 9. So it works on your machine (and PPC) but will not work on any others.

The correct approach is up on 58677#comment:5 with the os test changed to "< 9". although you do need to spend a minute reading it. I think we can convince Michael to do that, although he might prefer to sort out the math error (which is not actually even noted in this ticket!).

At some point I may try to fix up the extension handling for 64 bit Intel Leopard, but -- whew -- when?

[rmottola (Riccardo)]

Oh...I think the goal is t enable libc++ exactly on 10.4 and 10.5 running intel only, PPC being always excluded. On which others should it be enabled?

The solution would in any case also solve ​https://trac.macports.org/ticket/58578 but I see TRAC has no means of setting related bugs. Ayway we can close both bugs once we find and agree on a solution.

[kencu (Ken)]

One fix for 58578 is to force libc++ on Intel 10.5 and newer, and on no other systems. This was the easiest of the available fixes to suggest to you, and that's what I did myself.

[rmottola (Riccardo)]

Oh sorry... then of course the original fix of "< 9" is fine!

[rmottola (Riccardo)]

oh I see the issue still h appens and it is open. Any concerns about the proposed fixes?

[rmottola (Riccardo)]

as an added note.... since there is a line that says "avoid circular dependency" cmake-clang. I cannot compile cmake with clang 3.7 on 10.5!

on x86_64, I get:

Error when bootstrapping CMake:
Cannot find a C++ compiler that supports both C++11 and the specified C++ flags.
Please specify one using environment variable CXX.
The C++ flags are "-pipe -Os -fpermissive -D_GLIBCXX_USE_CXX11_ABI=0 -stdlib=macports-libstdc++ -arch x86_64".
They can be changed using the environment variable CXXFLAGS.
See cmake_bootstrap.log for compilers attempted.

Compiling with gcc 6.5 fails too! so.... while I can upgrade with clang 5.0, I forsee an issue here for fresh installs.

[kencu (Ken)]

Things are really in flux just now -- MacPorts 2.6 is coming out any day now, and everything is going to change on Intel systems 10.6 to 10.8 very shortly. So there is some distraction due to that.

Very few people use a Mac 10.5 Intel system, so you're kind of a niche (but important) user base there.

My plan, once the dust settles, is to try to sell the idea to treat 10.5 Intel like 10.6 Intel (once I get clang-8.0 actually building on 10.5 Intel). That will be the easiest solution. Then 10.5 intel will also default to libc++, just like 10.6 Intel will be doing, and these wacky (and irritating) inconsistencies between gcc and clang and the libgcc headers and the libc++ headers will mostly GO AWAY! Problem solved.

We will see how long 10.4 and 10.5 PPC support lasts with gcc and libgcc. Maybe a while, if I can keep it quiet and under the radar without too many tickets showing up about it. If there is too much hassle, the drumbeat is getting louder and louder to just cut support and be done with it. We'll see...it will happen sooner or later.

For right now -- the next month or so -- please force cmake to build against libc++ on 10.5 Intel as you did above, and then you should be OK pending the eventual fallout that is coming from the MP 2.6 rollout.

[kencu (Ken)]

So much has changed in legacysupport since this ticket was opened, and unfortunately we have a situation where legacysupport can't be upgraded any more, as some commits broke the build of legacy support on most of the legacy systems that it was designed to support :>

So first we need to get that sorted out, then we might dig in on why the asm instructions for realpath seem to have a different appendix on 64 bit systems. This might already have been addressed by some of ionic's tweaks to legacysupport, I can't say.

For any users out there, we did add an emergency bailout for realpath wrapping, and if you define this __DISABLE_MP_LEGACY_SUPPORT_REALPATH_WRAP__ then you should be in business while this gets sorted out.

[kencu (Ken)]

Riccardo, please try this:

in /opt/local/include/LegacySupport/stdlib.h please try just changing this:

extern char *realpath(const char * __restrict, char * __restrict)

to this:

extern char *realpath(const char * __restrict, char * __restrict) __DARWIN_EXTSN(realpath);

and then see how things work for you.

[rmottola (Riccardo)]

Actually, it fails;

rts_graphics_poppler/poppler/work/poppler-0.86.1/poppler/Catalog.cc
<inline asm>:1:1: error: invalid instruction mnemonic '_macports_legacy_realpath'
_macports_legacy_realpath
^
1 error generated.
make[2]: *** [CMakeFiles/poppler.dir/poppler/Catalog.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
<inline asm>:1:1: error: invalid instruction mnemonic '_macports_legacy_realpath'
_macports_legacy_realpath
^
1 error generated.
make[2]: *** [CMakeFiles/poppler.dir/poppler/Annot.cc.o] Error 1

My guts tell me that the macro DARWIN_EXTSN() is working on a just undefined realpath or something...

[rmottola (Riccardo)]

Interestingly, again, on this 10.5 i386 .... I undefined ENABLE_MP_LEGACY_SUPPORT_REALPATH_WRAP

and poppler conitnues building... but fails then with interminable link errors

lib/nspr/libplds4.dylib /opt/local/lib/nspr/libplc4.dylib /opt/local/lib/nspr/libnspr4.dylib -lm 
Undefined symbols for architecture i386:
  "std::__codecvt_utf16_base<wchar_t>::do_unshift(__mbstate_t&, char*, char*, char*&) const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::__codecvt_utf16_base<wchar_t>::do_encoding() const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::__codecvt_utf16_base<wchar_t>::do_max_length() const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::__codecvt_utf16_base<wchar_t>::do_always_noconv() const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::__codecvt_utf16_base<wchar_t>::do_in(__mbstate_t&, char const*, char const*, char const*&, wchar_t*, wchar_t*, wchar_t*&) const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::__codecvt_utf16_base<wchar_t>::do_out(__mbstate_t&, wchar_t const*, wchar_t const*, wchar_t const*&, char*, char*, char*&) const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::__codecvt_utf16_base<wchar_t>::do_length(__mbstate_t&, char const*, char const*, unsigned long) const", referenced from:
      vtable for std::codecvt_utf16<wchar_t, 1114111ul, (std::codecvt_mode)0> in PageLabelInfo.cc.o
  "std::ctype<char>::_M_widen_init() const", referenced from:
      std::ctype<char>::widen(char) const in PDFDoc.cc.o
  "std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::end() const", referenced from:
      GooString::sanitizedName(bool) const in GooString.cc.o
      FormWidgetSignature::getCheckedSignature(long long*) in Form.cc.o
      bool std::regex_search<std::char_traits<char>, std::allocator<char>, std::allocator<std::__cxx11::sub_match<__gnu_cx

....
....

I hope this is not due to the new ld64 I installed on @kencu's advice !!

[kencu (Ken)]

That last thing with poppler is a standard c++11 standard library mismatch. looks like (from the part I can see) nspr is being built against the wrong c++ standard library.

you can clean the build and try adding somethign like this to the Portfile:

compiler.cxx_standard 2011

and you might get luck doing that. My Leopard system is now fully based on libc++, just like 10.6 and above, and so I don't see these errors.

[michaelld (Michael Dickens)]

Is this still an issue for CMake 3.18.0? I find it builds cleanly for me on 10.5 PPC(32).

[kencu (Ken)]

Riccardo's problem here is trying to build 64 bit on Intel Leopard.

I think this is still broken -- legacysupport I believe doesn't cover this yet, and I haven't come to trying to fix it (and probably never will, TBH -- ).

[michaelld (Michael Dickens)]

Ah ... OK so PPC64 ... do I set that as the ARCH somewhere in maybe PREFIX/etc/macports.conf or something like that? I'm happy to test now that I have 2 capable G5's ...

[michaelld (Michael Dickens)]

It is also possible that CMake 3.18.0 fixes some issues here ... CMake is getting better overall with each release ...

[kencu (Ken)]

actually he's doing x86_64, but if it's ever fixed, might as well do both.

The (tricky) issue is with, I believe, the exact ASM-suffixed names we're using in our realpath wrap (and the other wrap) for our on-the-fly replacement functions.

they are not matching up for 64bit. But we must not break 32bit when fixing it!

[kencu (Ken)]

this happens on 32 bit too.

using clang5 or gcc7 seems to often get around it.

I don't understand it as yet, though. There was a change in clang's behaviour to make redefining the asm tag an error. It could be due to that, although the error message is not matching up with what was in the PR (I haven't gone into the clang source code to see if that changed since the original addition tho).

[kencu (Ken)]

This PR on phabricator references the issue -- this isn't the commit that brought the error in, but this is a PR that was going to change it to a warning (looks like it won't be accepted).

<​https://reviews.llvm.org/D16171>

In the legacy-support stdlib.h, we try to change the name of realpath to something else before including the system stdlib.h, but I guess that might not be working out. Have to run it through the preprocessor to see exactly what it is doing.

Why the legacy-support test suite works perfectly, and this issue only shows up in some ports, is not yet clear to me though...

[kencu (Ken)]

one thing I notice is that this error seems related to including

/usr/include/assert.h

in c++ code (so far).

[kencu (Ken)]

and never on PPC? Why not, if that's true?

[kencu (Ken)]

So stumbled across a few more ports where this occurs. So far the common thread is c++ code that includes <assert.h> I think.

No clang compiler worked when I tried it tonight on libde265, which showed the error. But building with gcc7 worked (i386).

So I guess that's why not on PPC (we don't use clang on PPC).

Running the legacy-support test suite on Leopard i386 with clang-7.0 works fine, including realpath replacement.

It only seems to be c++ code that includes <assert.h> where things get sticky.

<assert.h> is a bit weird -- it can be included multiple times. Whether that should matter I do not know, at present.

[kencu (Ken)]

This is the commit we would need to consider reverting on systems where we want to be able to redefine asm labels:

<​https://github.com/llvm/llvm-project/commit/6ee53bc0850c80287a6c5905af0ffd2101513021>

[kencu (Ken)]

Oh, it a really trivial patch, it looks like:

In this file here: clang/lib/Sema/SemaDecl.cpp

Do this:

  if (AsmLabelAttr *NewA = New->getAttr<AsmLabelAttr>()) {
    if (AsmLabelAttr *OldA = Old->getAttr<AsmLabelAttr>()) {
      if (OldA->getLabel() != NewA->getLabel()) {
        // This redeclaration changes __asm__ label.
-         Diag(New->getLocation(), diag::err_different_asm_label);
-         Diag(OldA->getLocation(), diag::note_previous_declaration);
+         // Diag(New->getLocation(), diag::err_different_asm_label);
+         // Diag(OldA->getLocation(), diag::note_previous_declaration);
      }
    } else if (Old->isUsed()) {
      // This redeclaration adds an __asm__ label to a declaration that has
      // already been ODR-used.
      Diag(New->getLocation(), diag::err_late_asm_label_name)
        << isa<FunctionDecl>(Old) << New->getAttr<AsmLabelAttr>()->getRange();
    }
  }

[kencu (Ken)]

I think I'm going to have to try that.

[kencu (Ken)]

has duplicate #63468

[kencu (Ken)]

I think what might possibly be happening here is that <assert.h> first includes <sys/cdefs.h> and then <stdlib.h>

#include <sys/cdefs.h>
#ifdef __cplusplus
#include <stdlib.h>
#endif /* __cplusplus */

and so when we try to process <stdlib.h> in legacysupport to redefine some asm tags, they have already been defined before we got there.

#define __DARWIN_EXTSN(sym)		__asm("_" __STRING(sym) __DARWIN_SUF_EXTSN)
#define __DARWIN_EXTSN_C(sym)		__asm("_" __STRING(sym) __DARWIN_SUF_EXTSN __DARWIN_SUF_NON_CANCELABLE)

I and not 100% sure this is exactly what is happening, but it seems plausible as a place to look for how to fix this.

A complete redo of our method of redefining symbols would be moderate work.

gcc and clang versions < 3.8 do not appear affected.

[kencu (Ken)]

The little patch to disable the error when redefining asm labels (to give clang the behaviour it had before this test was added in clang-3.8) does in fact work, and it allows software that failed with this error to now build. That looks suitably low risk, I believe, that we could consider that as a fix until/unless we come up with some more elegant method to use by tweaking <sys/cdefs.h> in the legacysupport headers, perhaps.

[kencu (Ken)]

patch fixes the build of libde265, and mosh both of which show this issue when building with clang-7.0 on leopard.

cmake used to show this issue too, but I just built the current cmake with an unmodified clang-9.0 and it worked fine.

[kencu (Ken)]

I tried to so something with the <assert.h> header , using an overlay for it in the legacysupport include files to somehow work around this, but nothing I tried would seem to work.

[kencu (Ken)]

In 24345c7733ed5eca7c5d1e836272a45221ee72f5/macports-ports (master):

clang-7.0: fixes for older systems

1. use cmake-bootstrap to reduce deps for building
2. use /usr/lib/libxml2.dylib to remove need for MP libxml2
3. allow relabelling asm labels to allow legacy support to work properly
4. minor whitespace cleanups

see: #58677

[kencu (Ken)]

this doesn’t occur any longer as the method we use to do this was changed