docker 能否解决 C 共享库不匹配的问题?
Can docker solve a problem of mismatched C shared libraries?
我正在尝试 运行 在 ubuntu (18.04) 主机上编写一些 haskell 代码,这些代码是在我的笔记本电脑上编译的。
host: 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
laptop: 4.14.74-1-MANJARO #1 SMP PREEMPT Fri Oct 5 14:16:52 UTC 2018 x86_64 GNU/Linux
我得到的错误是
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
经过一番研究得知这是因为我的笔记本电脑安装了 2.28 版的 glibc,但主机只有 libc6 2.27。
我在谷歌上搜索了一下,认为也许 docker 可以解决这个问题。但是,我刚刚使用以下 Dockerfile 创建了一个 docker 图像,但它不起作用(同样的 GLIBC_2.28 错误)
FROM fpco/stack-build:lts-12.9 as builder
RUN mkdir /opt/build
COPY . /opt/build
RUN cd /opt/build && stack build
FROM ubuntu:18.04
RUN mkdir -p /opt/myapp
WORKDIR /opt/myapp
RUN apt-get update && apt-get install -y \
ca-certificates
COPY --from=builder /opt/build/.stack-work/install/x86_64-linux-tinfo6/lts-12.9/8.4.3/bin .
CMD ["/opt/myapp/myapp-exe"]
我不知道现在该做什么。我有几个问题:
为什么我会首先遇到这个问题?我以为我在某处读到 glibc 向后兼容? (glibc 和 libc6 是一回事吗?)
有没有办法使用 docker 来解决这个问题?我可以 运行 我的构建过程在 ubuntu 图像中吗?例如FROM fcpo/stack-build:lts-12.9 and ubutu:18.04
,然后创建另一个 ubuntu 图像,我将我的二进制文件复制到其中?
有其他人 运行 参与过这个吗?如果是这样,您是否找到了解决方案(除了更改操作系统?)?
Why am I getting this problem in the first place? I thought I read somewhere that glibc is backwards compatible?
GLIBC 是 向后兼容(针对旧 GLIBC 构建的程序继续在较新的 GLIBC 上运行),但 inverse 不正确。
在你的例子中,你建立在一个较新的 (GLIBC-2.28) 系统上,并试图 运行 在一个较旧的系统 (GLIBC-2.27) 上。这不能保证有效(尽管它可能适用于足够简单的程序)。
Is there a way to use docker to get around this problem?
您需要针对您计划使用的最旧版本的 GLIBC 构建。
您可以通过多种方式实现此目的:
- 使用 Linux 旧的 Linux 交叉编译器
- 使用 chroot 构建环境
- 在构建时使用带有较旧 GLIBC 的 docker 容器。
或者您可以 运行 在具有您的程序所需的 GLIBC-2.28 的 docker 容器中。
我正在尝试 运行 在 ubuntu (18.04) 主机上编写一些 haskell 代码,这些代码是在我的笔记本电脑上编译的。
host: 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
laptop: 4.14.74-1-MANJARO #1 SMP PREEMPT Fri Oct 5 14:16:52 UTC 2018 x86_64 GNU/Linux
我得到的错误是
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
经过一番研究得知这是因为我的笔记本电脑安装了 2.28 版的 glibc,但主机只有 libc6 2.27。
我在谷歌上搜索了一下,认为也许 docker 可以解决这个问题。但是,我刚刚使用以下 Dockerfile 创建了一个 docker 图像,但它不起作用(同样的 GLIBC_2.28 错误)
FROM fpco/stack-build:lts-12.9 as builder
RUN mkdir /opt/build
COPY . /opt/build
RUN cd /opt/build && stack build
FROM ubuntu:18.04
RUN mkdir -p /opt/myapp
WORKDIR /opt/myapp
RUN apt-get update && apt-get install -y \
ca-certificates
COPY --from=builder /opt/build/.stack-work/install/x86_64-linux-tinfo6/lts-12.9/8.4.3/bin .
CMD ["/opt/myapp/myapp-exe"]
我不知道现在该做什么。我有几个问题:
为什么我会首先遇到这个问题?我以为我在某处读到 glibc 向后兼容? (glibc 和 libc6 是一回事吗?)
有没有办法使用 docker 来解决这个问题?我可以 运行 我的构建过程在 ubuntu 图像中吗?例如
FROM fcpo/stack-build:lts-12.9 and ubutu:18.04
,然后创建另一个 ubuntu 图像,我将我的二进制文件复制到其中?有其他人 运行 参与过这个吗?如果是这样,您是否找到了解决方案(除了更改操作系统?)?
Why am I getting this problem in the first place? I thought I read somewhere that glibc is backwards compatible?
GLIBC 是 向后兼容(针对旧 GLIBC 构建的程序继续在较新的 GLIBC 上运行),但 inverse 不正确。
在你的例子中,你建立在一个较新的 (GLIBC-2.28) 系统上,并试图 运行 在一个较旧的系统 (GLIBC-2.27) 上。这不能保证有效(尽管它可能适用于足够简单的程序)。
Is there a way to use docker to get around this problem?
您需要针对您计划使用的最旧版本的 GLIBC 构建。
您可以通过多种方式实现此目的:
- 使用 Linux 旧的 Linux 交叉编译器
- 使用 chroot 构建环境
- 在构建时使用带有较旧 GLIBC 的 docker 容器。
或者您可以 运行 在具有您的程序所需的 GLIBC-2.28 的 docker 容器中。