Opened 3 months ago
Closed 3 months ago
#70411 closed defect (fixed)
msp430-elf-gcc @9.3.1.2: version changes to @9.3.0 when installed
Reported by: | cooljeanius (Eric Gallager) | Owned by: | edilmedeiros (Edil Medeiros) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.3 |
Keywords: | haspatch | Cc: | |
Port: | msp430-elf-gcc |
Description
I recently attempted to upgrade msp430-elf-gcc. It built successfully, but then when it got to the actual installation part, it failed with this weird sqlite error:
---> Installing msp430-elf-gcc @9.3.0_0 DEBUG: elevating privileges for install: euid changed to 0, egid changed to 0. DEBUG: Executing org.macports.install (msp430-elf-gcc) Error: Failed to install msp430-elf-gcc: sqlite error: UNIQUE constraint failed: ports.name, ports.epoch, ports.version, ports.revision, ports.variants (2067) while executing query: INSERT INTO registry.ports (name, version, revision, variants, epoch) VALUES (?, ?, ?, ?, ?) DEBUG: Error code: registry::sqlite-error DEBUG: Backtrace: sqlite error: UNIQUE constraint failed: ports.name, ports.epoch, ports.version, ports.revision, ports.variants (2067) while executing query: INSERT INTO registry.ports (name, version, revision, variants, epoch) VALUES (?, ?, ?, ?, ?) while executing "registry::entry create $m(name) $m(version) $m(revision) $m(variants) $m(epoch)" invoked from within "registry::write { # store portfile set portfile_sha256 [sha256 file $m(portfile_path)] set portfile_size [file size $m(portfil..." (procedure "portimage::install" line 4) invoked from within "registry_install $regref" (procedure "portinstall::install_main" line 102) invoked from within "$procedure $targetname" DEBUG: dropping privileges: euid changed to 502, egid changed to 20.
Is my registry corrupted or something? I'm on x86_64 Big Sur with Xcode 13.
Attachments (1)
Change History (13)
Changed 3 months ago by cooljeanius (Eric Gallager)
Attachment: | main.log.bz2 added |
---|
comment:1 follow-up: 2 Changed 3 months ago by jmroot (Joshua Root)
Summary: | weird registry error when attempting to activate msp430-elf-gcc @9.3.0_0 → msp430-elf-gcc: version is not fixed |
---|
Replying to cooljeanius:
Is my registry corrupted or something? I'm on x86_64 Big Sur with Xcode 13.
Impossible to know without more information about its current state (like say port installed msp430-elf-gcc
). But it's probably something to do with the very strange and inconsistent way that this port sets its version
. Notice that you get:
:debug:clean Starting logging for msp430-elf-gcc @9.3.1.2_0
But then:
:notice:install ---> Installing msp430-elf-gcc @9.3.0_0
comment:2 Changed 3 months ago by cooljeanius (Eric Gallager)
Replying to jmroot:
Replying to cooljeanius:
Is my registry corrupted or something? I'm on x86_64 Big Sur with Xcode 13.
Impossible to know without more information about its current state (like say
port installed msp430-elf-gcc
). But it's probably something to do with the very strange and inconsistent way that this port sets itsversion
. Notice that you get::debug:clean Starting logging for msp430-elf-gcc @9.3.1.2_0But then:
:notice:install ---> Installing msp430-elf-gcc @9.3.0_0
$ port installed msp430-elf-gcc The following ports are currently installed: msp430-elf-gcc @9.3.0_0 (active)
But also:
$ port info msp430-elf-gcc msp430-elf-gcc @9.3.1.2 (cross, devel) Description: The GNU compiler collection, including front ends for C, C++, Objective-C and Objective-C++ for cross development for msp430-elf. Homepage: http://www.ti.com/tool/msp430-gcc-opensource Extract Dependencies: xz, bzip2 Build Dependencies: gettext Library Dependencies: msp430-elf-binutils, gmp, mpfr, isl, libiconv, libmpc, zlib Runtime Dependencies: msp430-gcc-support-files Platforms: darwin License: GPL-3+ Maintainers: Email: jose.edil+macports@gmail.com, GitHub: edilmedeiros Policy: openmaintainer
So I don't know...
comment:3 Changed 3 months ago by jmroot (Joshua Root)
If you already have 9.3.0 installed, it makes sense that trying to install what (sometimes) claims to be 9.3.0 again wouldn't work.
comment:4 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | edilmedeiros removed |
---|---|
Owner: | set to edilmedeiros |
Status: | new → assigned |
This part of the portfile must be removed:
# Bump back version so that newlib will compile correctly. pre-extract { version 9.3.0 }
An explanation is needed for why those lines were added so that a solution that actually works can be used. For example, maybe all that's needed is to change worksrcdir
to a value that uses the 9.3.0 version instead of the other one.
comment:5 follow-up: 6 Changed 3 months ago by edilmedeiros (Edil Medeiros)
Version number bothered me when updating this port. It is based on gcc 9.3.0, but Texas Instruments report their own patch to be version 9.3.1.2, which I decided to keep to align to what they report on the website. I have been using this port just fine on two machines (M3 Sonoma and x86_64 Monterrey) and the CI was checked before merging.
The pre-extract version rollback
# Bump back version so that newlib will compile correctly. pre-extract { version 9.3.0 }
was added so that the cross-gcc portgroup compiles fine. I could not make it work another way.
I just clean installed the port, and it worked fine. So I'll guess you have another gcc 9.3.0 cross compiler and it is triggering this.
comment:6 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to edilmedeiros:
The pre-extract version rollback
# Bump back version so that newlib will compile correctly. pre-extract { version 9.3.0 }was added so that the cross-gcc portgroup compiles fine. I could not make it work another way.
These lines cannot stay in the Portfile. They cause the problem described in this ticket. Ports cannot change the version number after setting it—not in a phase, not in a variant, not ever.
In case it's not clear, MacPorts will not automatically set the version back to the previous value after the extract phase, unless the user runs phases separately, e.g. sudo port extract
followed by a later phase like sudo port build
. And if I do run the phases separately like that, it fails with a "No such file or directory" error since it's looking for a 9.3.1.11 directory but there is actually a 9.3.0 directory.
comment:7 Changed 3 months ago by edilmedeiros (Edil Medeiros)
Thanks for clarifying.
I'll probably need some guidance to fix this, but let me tinker with the port again before asking for help.
comment:8 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)
I tried removing the block to see what you meant by "so that newlib will compile correctly". It failed at the extract phase:
Error: Failed to extract msp430-elf-gcc: symlink: /opt/local/var/macports/build/_Volumes_Shared_macports-ports_cross_msp430-elf-gcc/msp430-elf-gcc/work/gcc-9.3.1.2/ -> /opt/local/var/macports/build/_Volumes_Shared_macports-ports_cross_msp430-elf-gcc/msp430-elf-gcc/work/newlib-2.4.0/newlib: no such file or directory
The crossgcc portgroup is the one trying to create this symlink and assuming that the gcc version specified to crossgcc.setup
is also in the directory name, which in this case it isn't.
This patch lets me get past the extract, patch, and configure phases and I'm now waiting for the build to finish:
-
cross/msp430-elf-gcc/Portfile
a b 3 3 PortSystem 1.0 4 4 PortGroup crossgcc 1.0 5 5 6 # This post-extract block must be declared before the one created by crossgcc.setup. 7 post-extract { 8 ln -s gcc-${crossgcc.version} ${workpath}/gcc-${version} 9 } 10 6 11 crossgcc.setup msp430-elf 9.3.0 7 12 crossgcc.setup_libc newlib 2.4.0 8 13 … … checksums-append ${file_patch} \ 25 30 sha256 ec6472b034e11e8cfdeb3934b218e5bafbb7a03f3afc0e76536bd9c42653525b \ 26 31 size 283677 27 32 28 # Bump back version so that newlib will compile correctly.29 pre-extract {30 version 9.3.031 }32 33 33 depends_run port:msp430-gcc-support-files 34 34 35 35 depends_extract-append \ 36 36 port:bzip2 37 37 38 38 post-extract { 39 system -W ${workpath} "${prefix}/bin/bzip2 -dc ${distpath}/${file_patch}| /usr/bin/tar xf -"39 system -W ${workpath} "${prefix}/bin/bzip2 -dc [shellescape ${distpath}/${file_patch}] | /usr/bin/tar xf -" 40 40 } 41 41 pre-patch { 42 system -W ${worksrcpath} "/usr/bin/patch -p0 < ${workpath}/${name_patch}/gcc-${version}.patch"43 system -W ${workpath}/newlib-2.4.0 "/usr/bin/patch -p0 < ${workpath}/${name_patch}/newlib-2_4_0.patch"42 system -W ${worksrcpath} "/usr/bin/patch -p0 < [shellescape ${workpath}/${name_patch}/gcc-${crossgcc.version}.patch]" 43 system -W ${workpath}/newlib-2.4.0 "/usr/bin/patch -p0 < [shellescape ${workpath}/${name_patch}/newlib-2_4_0.patch]" 44 44 } 45 45 46 46 # gcc_system.diff: See https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=111632
I don't know if the port's revision needs to be increased.
comment:9 Changed 3 months ago by edilmedeiros (Edil Medeiros)
Yeah, it seems to do the trick. I built it and recompiled some projects with this patch and everything looks fine.
I'll submit a Github PR with it.
Sorry for messing this out.
comment:10 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | haspatch added |
---|---|
Summary: | msp430-elf-gcc: version is not fixed → msp430-elf-gcc @9.3.2.1: version changes to @9.3.0 when installed |
The build succeeded for me as well. I think there is no need to increase the revision but also no harm in doing so.
The PR is https://github.com/macports/macports-ports/pull/25019
Thanks for submitting it and no worries, we got it sorted out.
comment:11 Changed 3 months ago by ryandesign (Ryan Carsten Schmidt)
Summary: | msp430-elf-gcc @9.3.2.1: version changes to @9.3.0 when installed → msp430-elf-gcc @9.3.1.2: version changes to @9.3.0 when installed |
---|
comment:12 Changed 3 months ago by Edil Medeiros <78322931+edilmedeiros@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
bzipped main.log for msp430-elf-gcc