Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. Jan 26, 2024
  2. Jan 25, 2024
    • mergify[bot]'s avatar
      Merge pull request #9644 from cabalism/validate/overwritten-default-config · b99a830c
      mergify[bot] authored
      Ignore `IntegrationTests2/config/default-config`
    • Tom Smeding's avatar
      Ignore invalid Unicode in pkg-config descriptions (#9609) · 0b34b4ea
      Tom Smeding authored
      * Ignore invalid Unicode in pkg-config descriptions
      
      Previously, if any of the pkg-config packages on the system had invalid
      Unicode in their description fields (like the Intel vpl package has at
      the time of writing, 2024-01-11, see #9608), cabal would crash because
      it tried to interpret the entire `pkg-config --list-all` output as
      Unicode.
      
      This change, as suggested by gbaz in
        https://github.com/haskell/cabal/issues/9608#issuecomment-1886120831
      
      
      switches to using a lazy ByteString for reading in the output, splitting
      on the first space in byte land, and then parsing only the package
      _name_ to a String.
      
      For further future-proofing, package names that don't parse as valid
      Unicode don't crash Cabal, but are instead ignored.
      
      * Add changelog entry
      
      * cabal-install-solver: Add bounds on 'text'
      
      * No literal ASCII values, use 'ord'
      
      * Address review comments re invalid unicode from pkg-config
      
      * Add test for invalid unicode from pkg-config
      
      * Compatibility with text-1.2.5.0
      
      * Align imports
      
      * Handle different exception type
      
      * Use only POSIX shell syntax
      
      * Add invalid-input handler in pkg-config shim
      
      This is to appease shellcheck
      
      * Actually implement all required stuff in the pkg-config shim
      
      * Less exception dance
      
      * Fix shebang lines
      
      MacOS doesn't have /usr/bin/sh, and /bin/sh is the standard (for a POSIX
      shell) anyway
      
      * Don't expect a particular representation of invalid characters
      
      ---------
      
      Co-authored-by: default avatarmergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
  3. Jan 23, 2024
  4. Jan 22, 2024
  5. Jan 21, 2024
  6. Jan 20, 2024
    • mergify[bot]'s avatar
      Merge pull request #9554 from alt-romes/wip/romes/7339 · f2f9a03f
      mergify[bot] authored
      Add extraLibDirs to runtime lib search paths of library
    • Rodrigo Mesquita's avatar
      Add extraLibDirs to runtime lib search paths of library · addbcbfb
      Rodrigo Mesquita authored
      Runtime search paths are hard. Here's the current picture to understand
      why this patch exists:
      
      * When linking a shared library, GHC will include in the rpath entries
        of the shared library all the paths listed in the library dirs section
        of the installed package info of all packages the shared library
        depends on.
          * On darwin, GHC has special logic to inject the library dirs listed
            in the installed dependent packages info into the rpath section
            instead of passing the dirs as -rpath flags to the linker.
            However, only the dirs where used libraries are found are
            actually injected. The others are ignored. This works around
            limitations of the darwin loader.
      
      * Cabal, in addition, passes directly to the linker (via
        -optl-Wl,-rpath,...) the library dirs of packages the
        shared library for the package being built depends on.
          * In a vanilla cabal installation, this will typically only be the
            path to the cabal store and the path to the installed GHC's boot
            libraries store.
          * When using nix there will a different library dir per installed
            package. Since these lib dirs are passed directly to the linker as
            rpaths, we bypass the darwin loader logic and, for very big
            packages, on darwin, we could end up reaching the load command
            limit and fail linking. We don't address this situation in this MR.
      
      When we specify `extra-lib-dirs` in Cabal, these extra-lib-dirs will be
      added to the library dirs listed in the installed package info of the
      library they were specified for. Furthermore, when building a shared
      library, extra-lib-dirs will be passed as `-L` flags to the linker
      invocation. However, the same extra-lib-dirs will not be passed as
      `-rpath` to the linker.
      
      The end situation is as follows:
      
          1. The shared library `libA` built for a package `A` will be linked
             against some libraries `libExtra` found in extra-lib-dirs
             `extraA`.
      
          2. The RPATH section of `A` will NOT contain `extraA`, because we
             don't pass -rpath extra-lib-dirs when linking the library, but it
             will depend on `libExtra`.
      
          3. The installed package info of that package `A` will contain, in
             the library dirs section, the extra-lib-dirs `extraA` and the
             path to `libA`.
      
          4. When a package `B` depends on package `A`, it will include in the
             RPATH section of the shared library `libB` the lib dirs from the
             installed package info of `A`, i.e. `/path/to/libA` and `extraA`,
             and depends on `libA` and, transitively, on `libExtra`.
      
      The conclusion is:
      
          5. When we load `libB`, we will load `libA`, which is found in
             `/path/to/libA`, and, transitively, load `libExtra` which is
             found in `extraA` -- they are both found because both
             `/path/to/libA` and `extraA` are listed in the RPATH entries.
      
          6. However, if we load `libA` directly we will /NOT/ find
             `libExtra`, because `extraA` is not included in the RPATH
             entries.
      
      So, ultimately, what this commit fixes, is the failure described in (6),
      caused by the incorrect behaviour of (2), by specifying `-rpath
      extra-lib-dirs` when linking the shared library of a package, to include
      the extra lib dirs in the RPATH entries of that shared library (even
      though dependents of this library would already get the extra-lib-dirs
      in their RPATH, the library itself didn't, resulting in cabal#7339 and
      ghc#19350)
      
      Fixes #7339
      Fixes ghc#19350
      addbcbfb
    • Phil de Joux's avatar
      Add test cases that reproduce #7241. · 1e62b823
      Phil de Joux authored
      - Move project sdist tests to cabal-testsuite
      - Add --ignore-project test
      - Duplicate tests but without cabal.project
      - Add a cabal.project one folder up
      - Add a package Z in the root
      - Rerun --accept with more immediate parent project
      - Add a readme for the tests
      - Fix problems with uv package, update expected output
      - Add U and V modules
      - Explain what is wrong with cabal.dot-uv.test.hs
      - Add a note on cabal.no-project.test.hs
      - Explain what is wrong with cabal.sub-pq.test.hs
      - Explain what is wrong with cabal.sub-rs.test.hs
      - Explain what is wrong with cabal.dot-uv.test.hs
      - Leave a note explaining cabal.no-project.test.hs
      - Leave a note explaining cabal.project.test.hs
      - Leave a note explaining cabal.sub-pq.test.hs
      - Explain what is wrong with cabal.sub-rs.test.hs
      - Patches for project respecting behaviour
      - Explain root ignore-project and no-project tests
      - Add *.v2.test.hs variants exercising v2-sdist
      - Add v2 patches, test out not using <ROOT>
  7. Jan 19, 2024
  8. Jan 18, 2024
  9. Jan 17, 2024
  10. Jan 16, 2024
  11. Jan 13, 2024
Loading