Opened 20 months ago

Last modified 3 weeks ago

#58677 new defect

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

Reported by: rmottola (Riccardo) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: leopard i386 legacy-os Cc: michaelld (Michael Dickens), kencu (Ken), ccorn, rmottola (Riccardo)
Port: legacy-support legacy-support-devel

Description (last modified by jmroot (Joshua Root))

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

Attachments (1)

main.log (27.6 KB) - added by rmottola (Riccardo) 20 months ago.

Download all attachments as: .zip

Change History (39)

Changed 20 months ago by rmottola (Riccardo)

Attachment: main.log added

comment:1 Changed 20 months ago by jmroot (Joshua Root)

Cc: michaelld kencu added
Description: modified (diff)
Port: cmake added

comment:2 Changed 20 months ago by kencu (Ken)

Cc: ccorn added

comment:3 Changed 20 months ago by kencu (Ken)

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

comment:4 Changed 20 months ago by kencu (Ken)

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

comment:5 Changed 19 months ago by 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

comment:6 Changed 19 months ago by 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?

comment:7 Changed 19 months ago by 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).

comment:8 Changed 19 months ago by 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++
}

comment:9 Changed 19 months ago by rmottola (Riccardo)

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

comment:10 Changed 19 months ago by 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?

Last edited 19 months ago by kencu (Ken) (previous) (diff)

comment:11 Changed 19 months ago by 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.

comment:12 Changed 19 months ago by 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.

comment:13 Changed 19 months ago by rmottola (Riccardo)

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

comment:14 Changed 18 months ago by rmottola (Riccardo)

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

comment:15 Changed 18 months ago by 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.

Last edited 18 months ago by rmottola (Riccardo) (previous) (diff)

comment:16 Changed 18 months ago by 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.

comment:17 Changed 12 months ago by 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.

comment:18 Changed 12 months ago by 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.

comment:19 Changed 12 months ago by 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...

comment:20 Changed 12 months ago by 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 !!

comment:21 Changed 12 months ago by 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.

comment:22 Changed 9 months ago by mf2k (Frank Schima)

Keywords: legacy-os added; legacy removed

comment:23 Changed 7 months ago by 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).

comment:24 Changed 7 months ago by 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 -- ).

comment:25 Changed 7 months ago by 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 ...

comment:26 Changed 7 months ago by michaelld (Michael Dickens)

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

comment:27 Changed 7 months ago by 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!

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:28 Changed 4 months ago by 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).

Last edited 4 months ago by kencu (Ken) (previous) (diff)

comment:29 Changed 4 months ago by 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...

comment:30 Changed 4 months ago by kencu (Ken)

Summary: legacy support issue while building cmake (Leopard)legacy support "error: conflicting asm label" when building some ports

comment:31 Changed 4 months ago by kencu (Ken)

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

/usr/include/assert.h

in c++ code (so far).

comment:32 Changed 4 months ago by kencu (Ken)

Cc: rmottola added
Port: cmake removed

comment:33 Changed 4 months ago by kencu (Ken)

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

comment:34 Changed 4 months ago by kencu (Ken)

Port: legacy-support legacy-support-devel added

comment:35 Changed 4 months ago by 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.

comment:36 Changed 3 weeks ago by 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>

comment:37 Changed 3 weeks ago by 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();
    }
  }

comment:38 Changed 3 weeks ago by kencu (Ken)

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

Note: See TracTickets for help on using tickets.