On Wed, Jun 26, 2013 at 05:28:43PM -0400, Dubiousjim wrote:
> > Thanks for the suggestions with this. I did end up fixing it. It was a> very idiosyncratic issue that I don't expect others to encounter, but> just in case: I had manually created a /lib/libc.so -> libc.so.0.9.32> symlink, when I was trying to install/debug cross-compilers on my> system. I had lost track of that and neglected to remove it. apk audit> --system didn't report it because it's not a file that apk considers> owned. I didn't experience total build failures because I guess /lib> isn't one of the standard locations that gcc looks for libraries, so it> was just a few buildsystems that included -L/lib which would break,> because this symlink would shadow the script at /usr/lib/libc.so.> > (The only breaking buildsystems I came across were apk-tools and> cryptsetup, and some of the stub files that various ./configure scripts> try to build to see if various components exist on the host> system---which is how I in the end tracked this down.) Anyway, that> symlink shouldn't be there.
Oh, just noticed that the reason I had that bad symlink wasn't from my
cross-compiler experiments, but rather from this issue with Firefox back
in April. See the following...
On Tue, Apr 16, 2013 at 05:13:05PM +0200, Natanael Copa wrote:
> There have been som issues with firefox-19 and now also with firefox-20.> > To workaround it for now you can do:> > ln -s /lib/libc.so.0.9.32 /lib/libc.so> > the problem is some libc ffi in javascript.> > -nc
So others may conceivably also have this bad symlink, and should also
remove it. It doesn't seem to be necessary at the moment. (Our repos
have firefox-21...and firefox-22 is available upstream, though I haven't
yet managed to get it to successfully build for Alpine.)
And as I explained above, having this symlink in place will break some
builds.
--
Dubiousjim
dubiousjim@gmail.com
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Thu, Jul 18, 2013 at 09:26:07AM +0200, Natanael Copa wrote:
> > So others may conceivably also have this bad symlink, and should also> > remove it. It doesn't seem to be necessary at the moment. (Our repos> > have firefox-21...and firefox-22 is available upstream, though I haven't> > yet managed to get it to successfully build for Alpine.)> > > > And as I explained above, having this symlink in place will break some> > builds.> > Yes. The issue at hand also affected freebsd. I have posed a patch> upstream that should fix it once for all. (but havent had time to> follow it up and submit a proper patch for upstream review)> > https://bugzilla.mozilla.org/show_bug.cgi?id=878791
Ah, and I see this is moz-libc-filename.patch currently in
main/xulrunner.
--
Dubiousjim
dubiousjim@gmail.com
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Wed, 17 Jul 2013 16:59:28 -0400
Dubiousjim <dubiousjim@gmail.com> wrote:
> On Wed, Jun 26, 2013 at 05:28:43PM -0400, Dubiousjim wrote:> > > > Thanks for the suggestions with this. I did end up fixing it. It was a> > very idiosyncratic issue that I don't expect others to encounter, but> > just in case: I had manually created a /lib/libc.so -> libc.so.0.9.32> > symlink, when I was trying to install/debug cross-compilers on my> > system. I had lost track of that and neglected to remove it. apk audit> > --system didn't report it because it's not a file that apk considers> > owned. I didn't experience total build failures because I guess /lib> > isn't one of the standard locations that gcc looks for libraries, so it> > was just a few buildsystems that included -L/lib which would break,> > because this symlink would shadow the script at /usr/lib/libc.so.> > > > (The only breaking buildsystems I came across were apk-tools and> > cryptsetup, and some of the stub files that various ./configure scripts> > try to build to see if various components exist on the host> > system---which is how I in the end tracked this down.) Anyway, that> > symlink shouldn't be there.> > Oh, just noticed that the reason I had that bad symlink wasn't from my> cross-compiler experiments, but rather from this issue with Firefox back> in April. See the following...> > On Tue, Apr 16, 2013 at 05:13:05PM +0200, Natanael Copa wrote:> > There have been som issues with firefox-19 and now also with firefox-20.> > > > To workaround it for now you can do:> > > > ln -s /lib/libc.so.0.9.32 /lib/libc.so> > > > the problem is some libc ffi in javascript.> > > > -nc> > So others may conceivably also have this bad symlink, and should also> remove it. It doesn't seem to be necessary at the moment. (Our repos> have firefox-21...and firefox-22 is available upstream, though I haven't> yet managed to get it to successfully build for Alpine.)> > And as I explained above, having this symlink in place will break some> builds.
Yes. The issue at hand also affected freebsd. I have posed a patch
upstream that should fix it once for all. (but havent had time to
follow it up and submit a proper patch for upstream review)
https://bugzilla.mozilla.org/show_bug.cgi?id=878791
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---