Package Details: pandoc-static-git 3.2.r112.g2b60b1a1b-1

Git Clone URL: https://aur.archlinux.org/pandoc-static-git.git (read-only, click to copy)
Package Base: pandoc-static-git
Description: Conversion between markup formats (static build, dynamic Lua support)
Upstream URL: https://pandoc.org
Licenses: GPL-2.0-or-later
Conflicts: haskell-pandoc, pandoc, pandoc-bin
Provides: pandoc
Replaces: haskell-pandoc, pandoc, pandoc-bin
Submitter: gesh
Maintainer: gesh
Last Packager: gesh
Votes: 2
Popularity: 0.011037
First Submitted: 2021-10-27 21:34 (UTC)
Last Updated: 2024-08-08 17:43 (UTC)

Dependencies (5)

Required by (312)

Sources (1)

Pinned Comments

gesh commented on 2024-12-04 16:35 (UTC)

Note: when I wrote the commit message pushing for using ghc-9.6.5 I was under the mistaken impression that --disable-ld-override had been made the default for ghc's bindists. This is not the case -- ghc now only provides this as a build configuration option, see https://gitlab.haskell.org/ghc/ghc/-/issues/24565#note_570439 So to build this, the easiest way is to use a ghc provided by ghcup -- see https://www.haskell.org/ghcup/guide/#strategy-1-stack-hooks-new-recommended for how to get stack to use ghcup to fetch its compiler.

gesh commented on 2024-05-02 14:37 (UTC) (edited on 2024-05-02 17:07 (UTC) by gesh)

Warning: namcap complains the binary lacks FULL RELRO, PIE, and GNU_PROPERTY_X86_FEATURE_1_SHSTK

Have given up on trying to silence it, but am open to suggestions for improvement. The first appears to be generally problematic for Haskell1, and the last doesn't seem to be relevant to non-GCC applications (though this may be my ignorance speaking).

Latest Comments

gesh commented on 2024-12-04 16:35 (UTC)

Note: when I wrote the commit message pushing for using ghc-9.6.5 I was under the mistaken impression that --disable-ld-override had been made the default for ghc's bindists. This is not the case -- ghc now only provides this as a build configuration option, see https://gitlab.haskell.org/ghc/ghc/-/issues/24565#note_570439 So to build this, the easiest way is to use a ghc provided by ghcup -- see https://www.haskell.org/ghcup/guide/#strategy-1-stack-hooks-new-recommended for how to get stack to use ghcup to fetch its compiler.

gesh commented on 2024-05-11 22:32 (UTC)

@alerque thanks, noted. GHC does seem to support PIE according to its docs, so I'm not sure why no combination of flags I've tried successfully compiles PIE code (in fact, I was under the impression that that was the default, but this may be mistaken). RELRO I have no data at all on, though - if you know of a Haskell package that manages to pass namcap's RELRO lint, I'd appreciate the pointers to see what they're doing differently.

alerque commented on 2024-05-11 22:13 (UTC)

@gesh Thanks a lot for that Haskell hackery. I was so close but blundering around not really understanding how the whole ecosystem comes together.

As the maintainer of namcap I can say authoritatively you can ignore the SHSTK business for now. I'll release a namcap update that drops that rule by default until it is better supported by compilers. I'm less familiar with Haskell and the other two lints, but they certainly aren't blockers for this package either.

gesh commented on 2024-05-02 14:37 (UTC) (edited on 2024-05-02 17:07 (UTC) by gesh)

Warning: namcap complains the binary lacks FULL RELRO, PIE, and GNU_PROPERTY_X86_FEATURE_1_SHSTK

Have given up on trying to silence it, but am open to suggestions for improvement. The first appears to be generally problematic for Haskell1, and the last doesn't seem to be relevant to non-GCC applications (though this may be my ignorance speaking).

gesh commented on 2024-05-02 14:29 (UTC) (edited on 2024-05-02 14:30 (UTC) by gesh)

Sorry, I was dissatisfied with the hack I'd found to work around this, and was sitting on it until I could give something better. Thankfully, the workaround I have now is much cleaner now ghc-9.6.5 has been released, so I will be releasing a working version shortly.

In brief, the issue is that the default makepkg configuration sets LDFLAGS but not LD. GHC used to take this as its cue to select its own choice of LD. However GHC would not check that its choice of LD supports LDFLAGS. This is a problem for dependencies with C components, which get linked using this LD.

A fix1 for this has landed in ghc 9.6.5 on 2024-04-16, and ghc's installed using the current ghcup HEAD (starting with 7a684ad2) will have --disable-ld-override passed, which also fixes the issue.

(In case this is relevant for the future, the original hack I was using exploited the fact that in prepare(), LDFLAGS is not marked for export, so pre-building dependencies there would avoid this bug (since user-facing packages usually don't have C components))

alerque commented on 2024-04-30 13:27 (UTC)

I fail to understand how you can build this right now. I started having trouble with my pandoc-sile-git package when trying to get it up to 3.1.13 parity and decided to see how you got around the issues. Apparently you haven't, because I get this when trying to build in a clean chroot:

configure: error: Failed to determine machine word size. Does your toolchain actually work?

gesh commented on 2024-04-15 20:02 (UTC)

Thanks for pointing it out, updated my other packages as well.

alerque commented on 2024-04-13 19:56 (UTC)

You can't have a VCS package using Git sources without specifying makedepends=(git). Can you please add that?