Building "poppler" failed

2024-03-10 Thread Dave Horsfall
High Sierra 10.13.6 on ancient MBP.

Doing my weekly "port upgrade outdated", it went belly-up here:

-

--->  Building poppler   
Error: Failed to build poppler: command execution failed 
Error: See 

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/main.log
 
for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe 
there
is a bug.
--->  Some of the ports you installed have notes:
  libomp has the following notes:
To use this OpenMP library:
 * For clang-3.8+, or clang-3.7 with +openmp variant:
add "-fopenmp" during compilation / linking.
 * For clang-3.7 without +openmp variant, use:
"-I/opt/local/include/libomp -L/opt/local/lib/libomp -fopenmp"
  libpsl has the following notes:
libpsl API documentation is provided by the port 'libpsl-docs'.
Mon Mar 11 06:41:15 AEDT 2024
bash-3.2% locate charconv
/opt/local/include/gcc/c++/bits/charconv.h
/opt/local/include/gcc/c++/charconv
/opt/local/include/libcxx/v1/charconv

-

The main.log is attached (and I have no idea what "poppler" is).

Thanks.

-- Dave

main.log
Description: main.log


Re: MacPorts vs. Apple compiler issues, Handle

2024-03-10 Thread Riccardo Mottola via macports-users

Hi Joshua,

Joshua Root wrote:

MacPort installs:
$ clang-mp-9.0 --version
clang version 9.0.1

Apple:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)

Is there some Apple "trick" or is it the slight compiler difference in
version?


The version difference is less slight than you might think. Apple 
clang version numbers are unrelated to the version number of the 
llvm.org release they are based on. Apple clang 9.1.0 is closest to 
the clang-5.0 port.

Aha, I supposed that the number in parenthesis would match, but not.
Do you think it make sense for me to try clang5 or clang6?

The name collision looks genuine however. I can only assume that 
MacTypes.h is not included or is preprocessed differently based on 
different defines in the other compiler.


Do you think an issue in MacPorts compiler or a problem with the code? 
On Linux and FreeBSD  ArcticFox compiles with gcc13 and clang10, but 
this is an issue specific to the Mac code path, so not directly comparable.


I checked XPCShellEnvironment.cpp, there is no direct inclusion of 
MacTypes.h


Riccardo


Re: mozjs102

2024-03-10 Thread Dave Allured - NOAA Affiliate via macports-users
Following Ryan's suggestion, I am working on an update which should remove
the mozjs102 dependency, and enable gjs and glade for Sonoma.  Please try
the portfile from PR https://github.com/macports/macports-ports/pull/22974 .


On Thu, Mar 7, 2024 at 5:22 PM Lukas Oberhuber  wrote:

> i was never able to get gjs to work (at least when included in GIMP. It
> did compile, at least when I last tried (which was at least a year ago).
>
> On Thu, 7 Mar 2024 at 12:23, Ryan Schmidt  wrote:
>
>> On Mar 6, 2024, at 06:13, Gregory Dodwell wrote:
>>
>>
>> 
>> Will there ever be a mozjs102 port for the Sonoma version of MacPorts
>> 2.9.1?
>>
>> I can't install Glade without it. On the MacPorts bugs re mozjs102 page
>> there's a big red 'X' near the Sonoma version.
>>
>> Any plans for an update?
>>
>>
>> Nobody maintains this port. Somebody has to volunteer to investigate and
>> fix the problem. This is the bug report:
>>
>> https://trac.macports.org/ticket/68511
>>
>> mozjs115 does build on Sonoma so perhaps a fix already exists that can be
>> backported to mozjs102.
>>
>> And/or maybe the ports that depend on mozjs102 (currently only gjs and
>> gjs-devel) can switch to mozjs115.
>>
>


Re: mozjs102

2024-03-10 Thread Dave Allured - NOAA Affiliate via macports-users
On Thu, Mar 7, 2024 at 5:22 PM Lukas Oberhuber  wrote:

> i was never able to get gjs to work (at least when included in GIMP. It
> did compile, at least when I last tried (which was at least a year ago).
>
> On Thu, 7 Mar 2024 at 12:23, Ryan Schmidt  wrote:
>
>> On Mar 6, 2024, at 06:13, Gregory Dodwell wrote:
>>
>>
>> 
>> Will there ever be a mozjs102 port for the Sonoma version of MacPorts
>> 2.9.1?
>>
>> I can't install Glade without it. On the MacPorts bugs re mozjs102 page
>> there's a big red 'X' near the Sonoma version.
>>
>> Any plans for an update?
>>
>>
>> Nobody maintains this port. Somebody has to volunteer to investigate and
>> fix the problem. This is the bug report:
>>
>> https://trac.macports.org/ticket/68511
>>
>> mozjs115 does build on Sonoma so perhaps a fix already exists that can be
>> backported to mozjs102.
>>
>> And/or maybe the ports that depend on mozjs102 (currently only gjs and
>> gjs-devel) can switch to mozjs115.
>>
>>


Re: MacPorts vs. Apple compiler issues, Handle

2024-03-10 Thread Joshua Root

MacPort installs:
$ clang-mp-9.0 --version
clang version 9.0.1

Apple:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)

Is there some Apple "trick" or is it the slight compiler difference in
version?


The version difference is less slight than you might think. Apple clang 
version numbers are unrelated to the version number of the llvm.org 
release they are based on. Apple clang 9.1.0 is closest to the clang-5.0 
port.


The name collision looks genuine however. I can only assume that 
MacTypes.h is not included or is preprocessed differently based on 
different defines in the other compiler.


- Josh



MacPorts vs. Apple compiler issues, Handle

2024-03-10 Thread Riccardo Mottola via macports-users

Hi!

I am wondering about differences between Apple clang and MacPorts clang.
I tried to compile ArcticFox on 10.13, but in back compiatibility (10.9 
target on 10.11 SDK got through MacPorts)


Using exactly the same configuration options, MacPort clang 9.0 fails with:

169:29.18 
/Users/multix/code/Arctic-Fox/ipc/testshell/XPCShellEnvironment.cpp:76:13: 
error: reference to 'Handle' is ambiguous

169:29.18 Environment(Handle global)
169:29.18 ^
169:29.18 
/opt/local/Developer/SDKs/MacOSX10.11.sdk/usr/include/MacTypes.h:249:41: 
note: candidate found by name lookup is 'Handle'

169:29.18 typedef Ptr *   Handle;
169:29.18 ^
169:29.18 
/Users/multix/code/Arctic-Fox/obj-x86_64-apple-darwin17.7.0/dist/include/js/RootingAPI.h:381:25: 
note: candidate found by name lookup is 'JS::Handle'

169:29.18 class MOZ_NONHEAP_CLASS Handle : public js::HandleBase
169:29.18 ^
169:29.18 1 error generated.


However using apple's clang, all works fine.

MacPort installs:
$ clang-mp-9.0 --version
clang version 9.0.1

Apple:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)

Is there some Apple "trick" or is it the slight compiler difference in 
version?


Thanks,

Riccardo


Re: I just wanted to upgrade my older MacPorts version

2024-03-10 Thread Riccardo Mottola via macports-users

Hi,

xmar...@iqf.csic.es wrote:
The “sudo port upgrade outdated” is running, but the question know is, 
how can I run in the future the equivalent to the older “sudo port 
selfupdate”?
I suppose that since you got the repository in git, you just need to do 
a "git pull" to upgrade it and subsequently "sudo port -v sync".


Essentially Step 1 becomes a git pull, Step 2 can be skipped, Step 3 
repeated.


I too have a similar issue, at work I cannot access the web resources, a 
proxy is usually needed. At home though I can use it, so I run 
selfupdate at home or over a mobile connection.


Hope that helps, I did not test it.

Riccardo