poppler fails to build - missing charconv on some systems

[rmottola (Riccardo)]

On 10.5 building with clang 11

missing header? who should provide it?

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-24.01.0/fofi/FoFiType1.cc:31:10: fatal error: 'charconv' file not found
#include <charconv>
         ^~~~~~~~~~

1 error generated.

[rmottola (Riccardo)]

Alternative attempt to compile with gcc fails: ​https://trac.macports.org/ticket/67266

[ryandesign (Ryan Carsten Schmidt)]

Looks like charconv is a standard C++17 header.

[rmottola (Riccardo)]

@ryandesign does it mean we need some super-modern version of libgcc to support it?

[kencu (Ken)]

looks like it was added in gcc 8.1

​https://github.com/gcc-mirror/gcc/commit/804b7cc438701d94db8f958c2211c59f0357b757

It’s time for Tiger and Leopard to move up to gcc-13.

because gcc 8-12 offer nothing and will take forever to build, I suggest not supporting them at all on old systems. If support for them is left in, then it will be necessary to fix and build all of them to get to libgcc-13 , which is a pain.

[rmottola (Riccardo)]

@kencu why skip all releases? gcc 8.x is still a common compiler on linux and quite good. We could go to gcc 8.4 since we have 7, would be a more gradual approach. Do we have a ticket and put a dependency of poppler on this?

In the meanwhile I need to pin the previous release locally, I suppose.

[kencu (Ken)]

The way MacPorts is set up, if we want to add and use gcc13 as the new default gcc version, that will be OK when the build calls for gcc13. You would build libgcc13, and then gcc13, and then be on your way.

However, if all the intervening gccs (8-12) exist in MacPorts, building gcc7 will become very very onerous. To build gcc7 you would now need to build libgcc13, libgcc12, libgcc11, libgcc10, libgcc9, libgcc8, and then finally libgcc7.

All those intervening libgcc versions (8-12) are pretty much useless, but they still would all need to be built as per our libgcc structure. It would like a week or more.

Now -- if we dumped gcc8-12 (which are not needed for anything that I can see anyway) at least for older systems, and just have gcc7 and gcc13, then to build libgcc7 you only need to build libgcc13 (which you are building anyway), and then libgcc7.

SO that would be the logic for dumping all the (not needed) gccs between 8-12.

This could be possibly reworked -- libgcc7 could perhaps be made to only rely on libgcc13, even if the other gccs existed -- but that would require rethinking how we do the libgccN ports, and -- well -- consensus on that could take years.

[kencu (Ken)]

Of course, if someone has some live-or-die reason that gccN (8 >= N <= 12) is needed critically for something that simply cannot possibly build with either gcc13 or gcc7 -- well, OK then, no way out.

Gentlemen, start your processors! (and get a fan blowing on them, because building 7 gcc versions is going to take quite a while and warm up your apartment).

[rmottola (Riccardo)]

Replying to kencu:

Of course, if someone has some live-or-die reason that gccN (8 >= N <= 12) is needed critically for something that simply cannot possibly build with either gcc13 or gcc7 -- well, OK then, no way out.

Gentlemen, start your processors! (and get a fan blowing on them, because building 7 gcc versions is going to take quite a while and warm up your apartment).

I don't fully understand why we can just go from gcc7 to gg8 for now... all gcc version will build on the latest libgcc, libgcc8 or libgcc13

Anyway, here it is still cold, so I can run my MacBooks :) although one has a failing fan, sometimes it doesn't start! I need to check or it goes into thermal shutdown, couple of reboots help for now.

[rmottola (Riccardo)]

Bad news, this issue with charconv is a disease, it happens also on 10.13 High Sierra, which selects its own clang compiler (v10)... I wonder!!

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-24.03.0/fofi/FoFiType1.cc:31:10: fatal error: 'charconv' file not found
#include <charconv>
         ^~~~~~~~~~

[rmottola (Riccardo)]

Unfortunately, on 10.13 a gcc12 build is not enough:

Undefined symbols for architecture x86_64:
  "__ZNKSt3__14__fs10filesystem4path10__filenameEv", referenced from:
      __ZNSt3__14__fs10filesystem4path6appendINS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEEENS_9enable_ifIXsrNS1_13__is_pathableIT_XsrNS1_20__is_pathable_stringISC_vEE5valueEXsrNS1_24__is_pathable_char_arrayISC_NS_5decayISC_E4typeENS_12remove_constINS_14remove_pointerISI_E4typeEE4typeEXaasrNS_10is_pointerISI_EE5valuesrNS1_18__can_convert_charISO_EE5valueEEE5valueEXaantsrST_5valuesrNS1_18__is_pathable_iterISC_XsrNS_25__is_cpp17_input_iteratorISC_EE5valueEvEE5valueEEE5valueERS2_E4typeERKSC_ in pdfdetach.cc.o
  "__ZNKSt3__14__fs10filesystem4path16lexically_normalEv", referenced from:
      _main in pdfdetach.cc.o
  "__ZNSt3__14__fs10filesystem14__current_pathEPNS_10error_codeE", referenced from:
      _main in pdfdetach.cc.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

a gcc13 build instead fails with:

/opt/local/libexec/gcc13/libc++/include/c++/v1/atomic:2376:27:   required from here
/opt/local/libexec/gcc13/libc++/include/c++/v1/__chrono/duration.h:257:51: error: incomplete type 'std::__1::is_convertible<const long long int&, long long int>' used in nested name specifier
  257 |                is_convertible<const _Rep2&, rep>::value &&
      |        

not very promising...

A buildl with clang 11 yields lot of these warnings:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/poppler-24.03.0/utils/pdfdetach.cc:197:26: error: 'path' is unavailable: introduced in macOS 10.15
        std::filesystem::path basePath = savePath;

anyone did build popler < 101.15 ??

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

if we dumped gcc8-12 (which are not needed for anything that I can see anyway)

Ports exist for users to use them, not just for other ports to use. I haven't used gcc much lately, but I certainly find it handy to have many versions of clang available so that I can try to reproduce a problem with different clang versions to see in what version something broke or started to work.

[kencu (Ken)]

Jeremy dropped many clang versions over the years (and ld64 versions).

If there is no buildbot, building 7 or 8 gcc versions on powerpc to get to libgcc7 is a week long project.

[kencu (Ken)]

the difference between gcc and clang is the way libgcc cascades…

libgcc12 depends on libgcc13.

libgcc11 depends on libgcc 12.

etc. It’s a nightmare for building gcc 5, 6, or 7….

[rmottola (Riccardo)]

Replying to kencu:

the difference between gcc and clang is the way libgcc cascades…

libgcc12 depends on libgcc13.

libgcc11 depends on libgcc 12.

etc. It’s a nightmare for building gcc 5, 6, or 7….

It is a little bit tangent to poppler, we should have a separate discussion. I don't know about this "chain".

I'd gradually try to use gcc8 without jumping and not add all gcc version up to gcc13, but just "good ones". Convenience for compilers is good. Just right now I am struggling that ArcticFox compiles but crashes with newer compiler versions, so having the choice is useful.

There are better / more used compiler versions. E.g. I am not interested in gcc5, it has been used very little in Linux/BSD world. I try gcc 4.8, 6.x, 8.x.... in general it is the even numbers.