Possibility of providing x86 porting?

[zwh8800]

Thanks for excellent work :) Is it possible to provide a x86(not x86-64) porting of this package? I need run some very OLD binary on my server. Will it be taken into consideration?

[andyshinn]

The first thing that I would need is an x86 host OS to build on. What providers out there still provide 32bit VMs that I could try?

[zwh8800]

Maybe using VirtualBox could give you an x86 environment on your desktop computer

[frol]

@andyshinn How about using 32bit/ubuntu:14.04 or toopher/ubuntu-i386:12.04 Docker images? Why do you need x86 host OS?

[julrichkieffer]

Ideally use Alpine from multiarch/alpine:x86-latest-stable.

[djtm]

Yes the easiest way is to just use an image from docker's i386 repository, e.g. i386/alpine. Multiarach is more flexible. So far all Dockerfiles worked just the same when replacing alpine by i386/alpine on amd64.

[sgerrand]

Is there still need for this?

[julrichkieffer]

Ideally, yes. So that Java 8+ JRE or JEE can be installed, and support / run natively in Alpine docker containers.

Julrich

On 6 Jun 2016, at 19:07, Sasha Gerrand [email protected] wrote:

Is there still need for this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[sgerrand]

Ideally, yes. So that Java 8+ JRE or JEE can be installed, and support / run natively in Alpine docker containers.

You can use x86_64 versions of the Oracle and OpenJDK JVMs. 😉

Is there more to this argument that I'm missing?

[ramrei]

Hi Andy,

I am getting below error with alpine linux while trying to add Dynatrace java agent which works on Glibc based. Any suggestions will be helpful.

Error occurred during initialization of VM Could not find agent library /dynatrace/agent/lib64/libdtagent.so in absolute path, with error: Error relocating /dynatrace/agent/lib64/libdtagent.so: __isnan: symbol not found

Below is what i have added to have Glibc on Alpine #Download and Install Glibc added to Docker File RUN apk add --no-cache --update-cache bash CMD ["/bin/bash"] ENV GLIBC_PKG_VERSION=2.23-r3

RUN apk add --no-cache --update-cache curl ca-certificates bash &&
curl -Lo /etc/apk/keys/andyshinn.rsa.pub "https://github.com/andyshinn/alpine-pkg-glibc/releases/download/${GLIBC_PKG_VERSION}/andyshinn.rsa.pub" &&
curl -Lo glibc-${GLIBC_PKG_VERSION}.apk "https://github.com/andyshinn/alpine-pkg-glibc/releases/download/${GLIBC_PKG_VERSION}/glibc-${GLIBC_PKG_VERSION}.apk" &&
curl -Lo glibc-bin-${GLIBC_PKG_VERSION}.apk "https://github.com/andyshinn/alpine-pkg-glibc/releases/download/${GLIBC_PKG_VERSION}/glibc-bin-${GLIBC_PKG_VERSION}.apk" &&
curl -Lo glibc-i18n-${GLIBC_PKG_VERSION}.apk "https://github.com/andyshinn/alpine-pkg-glibc/releases/download/${GLIBC_PKG_VERSION}/glibc-i18n-${GLIBC_PKG_VERSION}.apk" &&
apk add --allow-untrusted glibc-${GLIBC_PKG_VERSION}.apk glibc-bin-${GLIBC_PKG_VERSION}.apk glibc-i18n-${GLIBC_PKG_VERSION}.apk

CMD ["/bin/bash"]

[sgerrand]

I am getting below error with alpine linux while trying to add Dynatrace java agent which works on Glibc based. Any suggestions will be helpful.

@ramrei: Please open a separate issue for this problem - it is unrelated to this issue opened by @zwh8800.

[mterron]

I have a (very old) piece of software that links to 32bit glibc. I can't change that dependency as the SDK is built against is 32bit only, so a 32bit glibc apk would be very useful indeed.

[tbodt]

There is now a somewhat stronger use case: iSH (https://ish.app) is built on 32-bit alpine linux, and various things need glibc to run. I will look into sending a PR for i386 support (and ideally every other arch, because there are no numbers between 1 and infinity.)

[marfier]

There’s now a bigger need for this. iSH (https://ish.app) runs on x86 Alpine, but a lot of things need glibc to run. Could we receive an update on this?

[tbodt]

See previous comment.

In the meantime, the gcompat or libc6-compat packages may be helpful.

[8thHalfHour]

Is this still in development and/or have a different solution at this point?

[sgerrand]

I haven't started any work on this as I don't have a need to run that architecture. If someone has time to write a patch to generate the requisite packages, I'm very happy to help them get it merged and released.

[8thHalfHour]

I guess I misunderstood your statement in 2016, then, asking if someone still needed this. Also, why is this topic still open if you have no interest developing it? I, personally, would really appreciate such an endeavor — exactly for working in iSH, as it allows me to work in a fast, minimal development environment directly from my iPad. UTM Isaac much more resource intensive solution and requires full emulation. I cannot tell you what a lifesaver iSH has been — except for this exact lack of support for 32-bit glibc. I can even load my own full alpine filesystem and not use the one iSH provides, but I cannot fix this problem. If someone more knowledgeable wasn’t able to at least provide instructions how to get something like this working on our own, would be extremely helpful. I’ve tried instructions within several docker images, but not one of them has managed to solve the issue. I guess I came here at least hoping I might get a bit more information about how to move forward, not exactly needing you to solve it for me. If you have no clue, though, that’s valid, too, obviously. Maybe it would help others who hit on this issue and see it’s open and see your response about if it is still needed to state exactly that you will not be pursuing this personally nor are you in a position for provide support on hope it could be done, then mark it closed.

I am not telling you what to do, btw. It would just stop those of us who do not have the awesome abilities you do from misunderstanding the conversations in this ticket and its status from bothering you about it ever again. And, on the other hand, if you do have an idea what someone can do to accomplish the goal, some concrete advice or other resources to look at would be great. But truly, if not, The best thing you could do is saying “no thanks” and closing this out.

Whatever you decide to do, though, I appreciate that you are beholden to no one to do anything. I just know that when people are researching a solution to a problem, they often hit on Place or person they know might have interest in either providing a solution or providing additional resources/information that might help them since it themselves. Putting this out there clearly, whatever your thoughts, would put all of that to rest and we shall haunt you no more. 👍🏻

[tbodt]

You may be interested in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/3202. It won't be merged into alpine because it doesn't work for programs that have dependencies beyond glibc - those would have been built against musl and wouldn't work right when loaded by glibc. But perhaps it's helpful for a port.

edit: https://gitlab.alpinelinux.org/tbodt/aports/-/commit/28595ec9ca4d8d626b5dce0c30a5ee023b055a70