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
---