Re: About rebuild of pandoc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Without trying to create a flame war, is there any chance to
reconsider going back to use static linking with Cabal and Haskell
programs?

I ask for this because in my case, it has been pretty painful trying
to use Cabal to build my code pulling multiple dependencies from
Hackage, as I suffered many issues with the linking. In my case most
of the issues have come with using the new feature "new-build", which
is great in how it solves dependency management but it fails pretty
often if you try to use it with dynamic linking.

I recently added a section on the wiki
(https://wiki.archlinux.org/index.php/Haskell#Building_statically_linked_packages_with_Cabal_.28without_using_shared_libraries.29)
explaining how to get your own cabal-install so that you can use
static linking back again, which is working as expected for me,
specially with "new-build".

I understand there are workarounds like you explained before on how to
ignore the global package DB, but not sure it's worth the trouble.
Also, I understand going back to static linking would create another
trade-off with fatter binaries, but IMHO static linking have important
benefits for us the devs and not so many drawbacks for the users of
packages statically compiled in the repos.

You mentioned before that when you asked to gather some feedback
before switching to dynamic linking you didn't get enough responses. I
understand that maybe not many Haskell devs on Arch reacted about it,
but now talking with other Haskell Arch users (specially on #haskell
IRC room), looks like everyone is having some friction with dynamic
linking and cabal for your own projects.

It feels to me that, as other communities such as the Golang one, have
reached the conclusion that dynamic linking isn't worth the trouble
with the extra complexity it brings in. Some people say that with
distros such as NixOS the problem goes away, no opinion on this, but
what matters to me is the current status is in Arch.

So guys, opinions on this?

—Ricardo


On Mon, Jul 3, 2017 at 11:10 AM, Felix Yan <felixonmars@xxxxxxxxxxxxx> wrote:
> On 07/03/2017 02:48 PM, Sebastian Reuße via arch-general wrote:
>> Sebastian Reuße via arch-general <arch-general@xxxxxxxxxxxxx> writes:
>>
>>> Felix Yan <felixonmars@xxxxxxxxxxxxx> writes:
>>
>>>> An idea is to provide an alternative package database in the ghc-static
>>>> package that only contains the boot libraries. You will need to ignore
>>>> global package database and specify that alternative path to use it.
>>>> Does this sound like useful?
>>
>>> That does sound preferable to not being able to do sandboxed static
>>> builds at all. I’ll also try pinging the Cabal folks when I get a
>>> chance; maybe it would make sense for cabal-install to be able to
>>> enforce reinstallation of dependencies without listing all packages
>>> explicitly.
>>
>> As a follow-up, Cabal currently tracks issue #1175 [1]. There seems to
>> be a disinclination against implementing «cabal install --reinstall
>> --dependencies-only» in preference to enabling Cabal to track installed
>> files and detect when registered packages have files missing. Since this
>> is tied up with improving Cabal’s package management facilities, my
>> guess is that this isn’t something that will see the light of day too
>> soon; so Felix’ proposed workaround of using an alternative global
>> package DB might be required in the meantime.
>
> Thanks for the info. Please try out ghc{,-static} 8.0.2-2 which is in
> [community-testing] now.
>
> This is an example of how it works for me:
>
> $ cabal sandbox init
> $ cabal install
> --ghc-pkg-option="--global-package-db=/usr/lib/ghc-8.0.2/static-package.conf.d"
> alex
>
> --
> Regards,
> Felix Yan
>




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux