#63468 closed defect (duplicate)
libde265 @1.0.8 fails to build on 10.5 i386: :info:build /opt/local/include/LegacySupport/stdlib.h:44:14: error: conflicting asm label
Reported by: | fhgwright (Fred Wright) | Owned by: | kencu (Ken) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) | |
Port: | libde265 legacysupport |
Description
It looks like this is a conflict between the LegacySupport and standard definitions of realpath(), perhaps caused by including the system header before the LegacySupport header. The error appears in lines 343-348 of the log, related to the compile command at line 339.
Attachments (1)
Change History (6)
Changed 3 years ago by fhgwright (Fred Wright)
comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | kencu added |
---|
comment:3 Changed 3 years ago by kencu (Ken)
Cc: | MarcusCalhoun-Lopez kencu removed |
---|---|
Owner: | set to kencu |
Status: | new → assigned |
Summary: | libde265 @1.0.8 fails to build on 10.5 i386 → libde265 @1.0.8 fails to build on 10.5 i386: :info:build /opt/local/include/LegacySupport/stdlib.h:44:14: error: conflicting asm label |
comment:4 Changed 3 years ago by kencu (Ken)
Cc: | MarcusCalhoun-Lopez added |
---|---|
Port: | legacysupport added |
This actually has nothing much to do with libde265, it's totally a legacysupport issue. But as it causes a failure in that port, we'll leave this here.
comment:5 Changed 3 years ago by kencu (Ken)
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
#58677 is the original ticket for this I believe. I'll add libde265 to that ticket
Note: See
TracTickets for help on using
tickets.
This issue goes back a few years now, and there are a number other tickets with the same error. Riccardo was running into this quite often, pushing the envelope as he did back then (he has since moved on to Linux, mostly, which is why we don't see Riccardo around here much any more).
The way legacysupport was set up in 2018, certain symbols were redefined to the new, fixed ones we wanted to use. At the time, this was just fine to do. But things then changed in the compiler world.
gcc still allows it, but as of a certain point, clang-7.0+ decided to disallow redefining symbols and make it an error.
If you build your port with gcc or with clang-6.0 or less, it will probably build OK (symbol redefinition is still allowed there).
Of late, MacPorts defaults to building with clang-7.0 if the gcc compilers have been disallowed.
I know how to reverse the change in clang-7.0+ to allow symbol redefinition again to "fix" this. I suggested doing that a year or two ago but was over-ruled and told that was a poor plan. We were supposed to redo legacysupport's symbol changing plan instead.
I don't have time or plans to ever do that, so I was going to go ahead and reverse the commit that disabled symbol redefinition on clang-7.0+ anyway, at least on < 10.6 where this is relevant.
For now, try building this port with some clang < 7, or with gcc, and it *should* build. Please report back if it does or doesn't.