Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#58441 closed defect (worksforme)

"port upgrade libgcc8" pulls libgcc9 instead (and fails, of course). Also affects gcc8 port

Reported by: mouse07410 (Mouse) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: libgcc8

Description

MacOS Mojave 10.14.4, Xcode-10.2.1.

libgcc8 port is screwed up - it mistakenly thinks that its upgrade it not 8.3.0_4, but libgcc9 (which I don't care to install, regardless).

$ port outdated
The following installed ports are outdated:
gcc8                           8.3.0_0 < 8.3.0_4         
libgcc                         1.0_0 < 2.0_0             
libgcc8                        8.3.0_0 < 8.3.0_3         
$ sudo port upgrade libgcc8
--->  Computing dependencies for libgcc9
--->  Fetching archive for libgcc9
--->  Attempting to fetch libgcc9-9.1.0_0.darwin_18.x86_64.tbz2 from https://packages.macports.org/libgcc9
--->  Attempting to fetch libgcc9-9.1.0_0.darwin_18.x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/libgcc9
--->  Attempting to fetch libgcc9-9.1.0_0.darwin_18.x86_64.tbz2 from http://aus.us.packages.macports.org/macports/packages/libgcc9
--->  Fetching distfiles for libgcc9
--->  Attempting to fetch gcc-9.1.0.tar.xz from https://distfiles.macports.org/gcc9
--->  Verifying checksums for libgcc9                                                
--->  Extracting libgcc9
--->  Configuring libgcc9
--->  Building libgcc9
Error: Failed to build libgcc9: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc9/libgcc9/main.log for details.
Error: Problem while installing libgcc9
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
$

This probably explains why - somebody put libgcc9 as a runtime dependency for libgcc8. As gcc8 depends on libgcc8, it cannot be updated either.

Complete log is attached.

Attachments (3)

main.log.zip (1.7 MB) - added by mouse07410 (Mouse) 5 years ago.
main.log for libgcc9. It does not explain why libgcc8 port suddenly decided that it needs libgcc9
port.upgrade.log (10.5 KB) - added by lemzwerg (Werner Lemberg) 5 years ago.
Output of port -v upgrade outdated
config.log (10.0 KB) - added by lemzwerg (Werner Lemberg) 5 years ago.
config.log of the 'intl' subdirectory

Download all attachments as: .zip

Change History (23)

Changed 5 years ago by mouse07410 (Mouse)

Attachment: main.log.zip added

main.log for libgcc9. It does not explain why libgcc8 port suddenly decided that it needs libgcc9

comment:1 Changed 5 years ago by mouse07410 (Mouse)

Remedied by Macports offering pre-built binary of libgcc9, but I still wonder why libgcc8 should depend on libgcc9.

comment:2 Changed 5 years ago by dyne2meter

I was able to fix the problem by uninstalling both libgcc9 and libgcc8, and then re-installing both ports.

Last edited 5 years ago by dyne2meter (previous) (diff)

comment:3 Changed 5 years ago by mf2k (Frank Schima)

The point is that it seems odd that libgcc8 requires libgcc9.

$ port deps libgcc8
Full Name: libgcc8 @8.3.0_5
Extract Dependencies: xz
Library Dependencies: 
Runtime Dependencies: libgcc9

comment:4 Changed 5 years ago by kencu (Ken)

The way this is set up now, the port people should be installing (and the one that is dependencied in other ports) is libgcc.

libgcc is a meta-port. It installs the latest version of libgcc that should be installed on a given system (depending on the system's capabilities), and it also can install certain bits of libgcc6,7,or8 that are needed for MacPorts but no longer available in the latest libgcc version, which is presently libgcc9.

It *is* getting more complicated, to be sure, and there have been some hiccups in birthing here and there, but Chris is doing a great job at keeping this all working.

The reason you're seeing libgcc8 having a runtime dep on libgcc9 is that libgcc8 is incomplete on many systems, and needs libgcc9 to fill in the rest of the required parts to make a whole libgcc installation.

Last edited 5 years ago by kencu (Ken) (previous) (diff)

comment:5 Changed 5 years ago by mf2k (Frank Schima)

So since the reporter says it is working for him, can we close this ticket?

comment:6 Changed 5 years ago by kencu (Ken)

I think so. Chris might still have some tweaking to do to the whole situation, but the essence of this ticket is basically "works as expected".

comment:7 Changed 5 years ago by kencu (Ken)

Resolution: worksforme
Status: newclosed

comment:8 Changed 5 years ago by mouse07410 (Mouse)

The way this is set up now, the port people should be installing (and the one that is dependencied in other ports) is libgcc.

I'm not sure I buy it, as I doubt a user would care to install a specific libgccX. A user may care to install a specific gccX. For example, I wanted to upgrade gcc8. libgcc8 was something that this port pulled as its dependency, and when it works OK the user doesn't even notice its existence. IMHO, a user may want to explicitly (re-)install this port only to repair something broken.

comment:9 Changed 5 years ago by kencu (Ken)

Maybe I can explain better -- we are always open to a "better way" if there is one, but this one has been hammered out over some years so I think you might find in the end it is quite well thought out.

I think I have this all correct, but there might always be someone with a correctional tweak here or there.

Due to factors of design and compatibility, all versions of gcc that can run on a given OS version need to use the same libgcc binary. Every version of gcc > gcc45 installed on a given OS version uses the same libgcc binary, which therefore has to be the latest one the OS version can support. Luckily these are always backward compatible, from gcc4.5 forward, so far.

Any other apparent libgcc versions installed are simply symlinks to that latest libgcc, although there are a few cases where older libraries that don't exist in new versions of libgcc are installed from old versions of libgcc for compatibility reasons.

The latest libgcc that that the OS version can support is either libgcc7, 8, or 9, depending on the OS version.

So if someone tries to install gcc8 on Mojave, they actually will get libgcc9 to support it, and MacPorts will symlink libgcc so that gcc8 is happy.

If you outright tried to force install libgcc8, you will just get libgcc9 anyway, because otherwise everything will break down. You cannot use libgcc8 on newer systems any longer (unless you are Chris or Marcus etc, and then if you did figure out how to do that inside MacPorts', things would start breaking, so don't do that).

Last edited 5 years ago by kencu (Ken) (previous) (diff)

comment:10 Changed 5 years ago by kencu (Ken)

here is my 10.6.8 setup, for example:

$ port contents libgcc6
Port libgcc6 contains:
  /opt/local/lib/libgcc/libasan.3.dylib
  /opt/local/lib/libgcc/libgfortran.3.dylib
$ port contents libgcc7
Port libgcc7 contains:
  /opt/local/lib/libgcc/libasan.4.dylib
  /opt/local/lib/libgcc/libcilkrts.5.dylib
  /opt/local/lib/libgcc/libgfortran.4.dylib
  /opt/local/lib/libgcc/libubsan.0.dylib
$ port contents libgcc8
--- everything else -- 

comment:11 Changed 5 years ago by mouse07410 (Mouse)

OK. If it works, it works.

I'm just pointing out that the naming and the dependency chain for this set of ports is rather counter-intuitive; and if/when something breaks, the user is left very much puzzled (as I was myself, merely trying to update/refresh gcc8, and getting a message that out of the blue libgcc9 failed to install).

But since I don't have a useful suggestion how to simplify it, I guess we'll keep it as is. ;-)

comment:12 Changed 5 years ago by lemzwerg (Werner Lemberg)

[da875ff3448c77c2365c0c5ec2b1c52281582c46]

macOS 10.7.5 11G63
Xcode 4.6.3 4H1503

As described above, port outdated shows

gcc8                           8.3.0_0 < 8.3.0_4         
libgcc                         1.0_0 < 2.0_1             
libgcc8                        8.3.0_0 < 8.3.0_5

on my box. However, doing sudo port upgrade libgcc as recommended above still results in

--->  Computing dependencies for libgcc9
--->  Building libgcc9
Error: Failed to build libgcc9: command execution failed
Error: See /opt/local/var/macports/logs/_opt_macports_macports-ports_lang_gcc9/libgcc9/main.log for details.

What shall I do?

comment:13 Changed 5 years ago by kencu (Ken)

do something like this:

sudo port clean libgcc9
sudo port -v upgrade outdated

and see where it winds up

Changed 5 years ago by lemzwerg (Werner Lemberg)

Attachment: port.upgrade.log added

Output of port -v upgrade outdated

comment:14 Changed 5 years ago by lemzwerg (Werner Lemberg)

Attached.

comment:15 Changed 5 years ago by kencu (Ken)

on your system, clang-3.4 is failing a "sanity check" during the libgcc9 build.

The detail of what exactly failed is in a file called config.log in your libgcc9 build directory. Post that if you can spot it.

I'll see if I can reproduce this on my 10.7 machine..

comment:16 Changed 5 years ago by lemzwerg (Werner Lemberg)

OK, it's file /opt/local/var/macports/build/_opt_macports_macports-ports_lang_gcc9/libgcc9/work/build/intl/config.log, attached.

Changed 5 years ago by lemzwerg (Werner Lemberg)

Attachment: config.log added

config.log of the 'intl' subdirectory

comment:17 Changed 5 years ago by lemzwerg (Werner Lemberg)

By the way, should this ticket be re-opened, assuming that you can reproduce the issue?

comment:18 Changed 5 years ago by kencu (Ken)

This would be a new ticket.

MacPorts is now trying to build gcc9 / libgcc9 using clang-3.4 as the compiler. This is a change.

Also, the mods to the cctools port mean that clang is being used as the assembler in most cases.

These two changes have ripple effects.

comment:19 Changed 5 years ago by kencu (Ken)

I'm afraid my 10.7 machines all have libgcc9 installed without any issues. I'm just running a rebuild now to see if anything might have changed since they were last updated.

comment:20 Changed 5 years ago by lemzwerg (Werner Lemberg)

Thanks for testing. I've just updated (and rebuilt) 'macports-base', followed by an update of 'macports-ports', and it worked now. Problem is gone :-)

Note: See TracTickets for help on using tickets.