texlive-bin @2022.62882_1+x11 build failure with gmp+mpfr in /usr/local

[boccio-john]

Sorry for my mixup about how to continue reporting the problem.

The original problem with qt5-qtbase has been fixed

I executed the commands

sudo port -v reclaim
sudo port selfupdate

as per your instructions.

The started the octave install again.

It got past "qt5-qtbase" without an error this time.

There were only three items left when it got an error on building texlive-bin.

texlive-basic texlive-fonts-recommended texlive-latex

So close but no cigar!

[boccio-john]

texlive-bin build failure main.log file

[jmroot (Joshua Root)]

Looks like you have x86_64 versions of gmp and mpfr installed in /usr/local. Hopefully there is some way to get the port to ignore them, but see wiki:FAQ#usrlocal.

[boccio-john]

Digging around.....

Two lines in main.log file indicate problem.

:info:build ld: warning: ignoring file /usr/local/lib/libmpfr.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

:info:build ld: warning: ignoring file /usr/local/lib/libgmp.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

If I go to /us/local/lib and check those files:

lrwxr-xr-x 1 root wheel 15 Nov 3 2014 libmpfr.dylib -> libmpfr.4.dylib

lrwxr-xr-x 1 root wheel 15 Nov 3 2014 libgmp.dylib -> libgmp.10.dylib

They both seem to indicate they were originally installed when I first Installed MacTex in 2014 and I am guessing (not a UNIX person) that the arrow indicates they have been replaced by later versions since I now have MacTex 2022 installed.

Why would the Macports install be using thes files from a different version of TeX?

Is the Macports build of texlive-bin getting confused by my having a different version of MacTeX on my computer?

All of my statements here may just be gibberish since I am not a UNIX expert?

Any technical help would be appreciated?

Thanks.

[jmroot (Joshua Root)]

Replying to boccio-john:

Digging around.....

Two lines in main.log file indicate problem.

:info:build ld: warning: ignoring file /usr/local/lib/libmpfr.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

:info:build ld: warning: ignoring file /usr/local/lib/libgmp.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

Yes, those are the lines that indicated the problem to me.

If I go to /us/local/lib and check those files:

lrwxr-xr-x 1 root wheel 15 Nov 3 2014 libmpfr.dylib -> libmpfr.4.dylib

lrwxr-xr-x 1 root wheel 15 Nov 3 2014 libgmp.dylib -> libgmp.10.dylib

They both seem to indicate they were originally installed when I first Installed MacTex in 2014 and I am guessing (not a UNIX person) that the arrow indicates they have been replaced by later versions since I now have MacTex 2022 installed.

Those are ​symbolic links, but that's not really relevant. The problem is just that an x86_64 library is being found when building for arm64.

Why would the Macports install be using thes files from a different version of TeX?

Is the Macports build of texlive-bin getting confused by my having a different version of MacTeX on my computer?

The FAQ entry I linked previously goes into this a bit, but the short answer is that many parts of the build system really want to look for headers in /usr/local/include and libraries in /usr/local/lib, and it's very difficult to get all of them to not do that. For example, the compiler treats those locations just like /usr/include and /usr/lib, but with a higher priority, i.e. things in /usr/local will be found before the system components in /usr (and there is no option to change this behaviour). We do what we can, but the only completely safe configuration is to not have anything installed in /usr/local.

[boccio-john]

Replying to jmroot:

Replying to boccio-john:

Digging around.....

Two lines in main.log file indicate problem.

:info:build ld: warning: ignoring file /usr/local/lib/libmpfr.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

:info:build ld: warning: ignoring file /usr/local/lib/libgmp.dylib, building for macOS-arm64 but attempting to link with file built for macOS-x86_64

Yes, those are the lines that indicated the problem to me.

If I go to /us/local/lib and check those files:

lrwxr-xr-x 1 root wheel 15 Nov 3 2014 libmpfr.dylib -> libmpfr.4.dylib

lrwxr-xr-x 1 root wheel 15 Nov 3 2014 libgmp.dylib -> libgmp.10.dylib

They both seem to indicate they were originally installed when I first Installed MacTex in 2014 and I am guessing (not a UNIX person) that the arrow indicates they have been replaced by later versions since I now have MacTex 2022 installed.

Those are ​symbolic links, but that's not really relevant. The problem is just that an x86_64 library is being found when building for arm64.

Why would the Macports install be using thes files from a different version of TeX?

Is the Macports build of texlive-bin getting confused by my having a different version of MacTeX on my computer?

The FAQ entry I linked previously goes into this a bit, but the short answer is that many parts of the build system really want to look for headers in /usr/local/include and libraries in /usr/local/lib, and it's very difficult to get all of them to not do that. For example, the compiler treats those locations just like /usr/include and /usr/lib, but with a higher priority, i.e. things in /usr/local will be found before the system components in /usr (and there is no option to change this behaviour). We do what we can, but the only completely safe configuration is to not have anything installed in /usr/local.

Thanks for the information. As I said I am not a UNIX expert. Does this mean that I cannot do anything about those x86_64 libraries? I suspect MacTeX is putting them there. Can I remove them? Is there no way the mac ports.conf file can be set to ignore them? I assume when someone who is more of an expert than me gets around to this port they will make it work somehow and therefore I just have to be patient and try again in the future. Luckily I can still use the Version 6.2 which has been put together as an APP and I do not need to compile anything.