Deploying Yesod to Heroku, Can't Build Statically

Deploying Yesod to Heroku, can't build statically

I have no idea what Yesod is, but I know exactly what each of your other errors means.

First, you should not try to link statically. The warning you get is exactly right: if you link statically, and use one of the routines for which you are getting the warning, then you must arrange to run on a system with exactly the same version of libc.so.6 as the one you used at build time.

Contrary to popular belief, static linking produces less, not more, portable executables on Linux.

Your other (static) link errors are caused by missing libopenssl.a at link time.

But let's assume that you are going to go the "sane" route, and use dynamic linking.

For dynamic linking, Linux (and most other UNIXes) support backward compatibility: an old binary continues to work on newer systems. But they don't support forward compatibility (a binary built on a newer system will generally not run on an older one).

But that's what you are trying to do: you built on a system with glibc-2.14 (or newer), and you are running on a system with glibc-2.13 (or older).

The other thing you need to know is that glibc is composed of some 200+ binaries that must all match exactly. Two key binaries are /lib/ld-linux.so and /lib/libc.so.6 (but there are many more: libpthread.so.0, libnsl.so.1, etc. etc). If some of these binaries came from different versions of glibc, you usually get a crash. And that is exactly what you got, when you tried to place your glibc-2.14 libc.so.6 on the LD_LIBRARY_PATH -- it no longer matches the system /lib/ld-linux.

So what are the solutions? There are several possibilities (in increasing difficulty):

1. You could copy ld-2.14.so (the target of /lib/ld-linux symlink) to the target system, and invoke it explicitly:

   /path/to/ld-2.14.so --library-path <whatever> /path/to/your/executable
   

   This generally works, but can confuse an application that looks at argv[0], and breaks for applications that re-exec themselves.

2. You could build on an older system.

3. You could use appgcc (this option has disappeared, see this for description of what it used to be).

4. You could set up a chroot environment matching the target system, and build inside that chroot.

5. You could build yourself a Linux-to-olderLinux crosscompiler

shakespeare-js fails to compile on Heroku

The problem is that the type PreConvert changed between shakespeare-1.0.2 and shakespeare-1.0.3.

In the older version, preEscapeBegin and preEscapeEnd were fields of the constructor PreConvert, but they have been removed in version 1.0.3.

So the solution is to

• use the older version of shakespeare, specify shakespeare < 1.0.3 or
• use a new enough version of shakespeare-js, specify shakespeare-js >= 1.1.2.

(There may be further adjustments necessary if you use the newer shakespeare version, I haven't tried.)

Heroku not deploying build due to dependency issue

I had the same issue a few days ago (early June) while deploying my React app on Heroku as well. It seems the problem was caused by the npm version update. By default, Heroku uses the latest stable version of node and npm as the building engines, but it might lead to conflicting dependencies if you use a previous version of them.

So, if it works completely fine locally but this issue happens while deploying it on Heroku, here is the solution:

Use node --version and npm --version to check out the versions on your local instance, and then add them under engines section in your package.json file, like this (replace 16.0.0 and 7.10.0 with the versions you have):

"engines": {
    "node": "16.0.0",
    "npm": "7.10.0"
},

then redeploy the app on Heroku. Problem should be fixed.

Mail configuration for Yesod app on Heroku

I don't have specific Heroku experience, but I usually use mime-mail-ses to send mail via Amazon.

Avoiding too specific dependencies

It's not very confidence inspiring. They should be building on a stable baseline release, it could just be a virtual install. Some versions of Linux, copy a build environment so packages aren't linked to updated library versions.

The openSUSE build service, lets devolopers build binary packages, for a wide variety of http://openbuildservice.org/about/

IIRC readline is a GPL program and checking at http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html#Availability suggests it is GPL v 3 so they may be in violation of the GPL, if they are using libreadline functions and should provide you with the source to their library. I am not sure if you are meaning rpm/apt package dependencies, or their library is actually calling libreadline.

You can always extract files from rpm or apt packages, if necessary so avoiding software manager issues, caused by poor packaging.

Deploying Yesod web app

The stack build command gives me the hints:

my-project-0.0.0: install
Installing library in
/home/a/my-project/.stack-work/install/x86_64-linux/lts-3.13/7.10.2/lib/x86_64-linux-ghc-7.10.2/my-project-0.0.0-Khn8lQEgR1HARzYGStlvPe
Installing executable(s) in
/home/a/my-project/.stack-work/install/x86_64-linux/lts-3.13/7.10.2/bin
Registering my-project-0.0.0...

The executable is located in /home/a/my-project/.stack-work/install/x86_64-linux/lts-3.13/7.10.2/bin. I could copy the files (executable, static, and config) in ~/deployment directory to check the Yesod works fine.

standard solution for /lib64/libc.so.6: version `GLIBC_2.14' not found

The easiest solution is to simply create a "build server" which you use for your production builds, and keep this server on the oldest version of everything you need to support, including glibc.

This can be done using a VM inside your development server if you don't want to use a physical machine.

Yesod tutorial compile error: Not in scope: ‘runResourceT’

I think that an older version of Data.Conduit might have exported ResourceT directly, but nowadays you need to import it explicitly with

import Control.Monad.Trans.Resource

How to use image under static directory as background in Yesodweb?

Maybe you were using lucius template, the real css file was autogenerated in temporary location /tmp on runtime and used the relative path. What you need is type-safe URL which verifies URL validity on compile time.

If you're using scaffold template, then you can represent it as @{StaticR img_bg_jpg} according to this

Note: With old version of yesod-static and template, stack clean may be required to reflect changes in static directory.

---

Related Topics