Created attachment 383886 [details, diff] ebuild path Please see the attached patch. Simpler than your average cross-compile fix. If you don't specify an OGG prefix using --with-ogg then FLAC assumes -I/usr/include and -L/usr/lib, which is bad news when you're cross-compiling. Specifying --with-ogg prevents these flags from being added at all. Giving this option together with --disable-ogg has no effect so no extra logic is needed there. This is almost identical to bug #521426 (speex) except that in the FLAC case, the OGG m4 script has an extra clause that negates the need to explicitly give a prefix.
This isn't enough to fix things, basically the ogg m4 script should probably be patched to use pkgconfig.
It should but convincing upstream can be hard work. I believe this would work sufficiently for Gentoo when we are installing things where the toolchain will find them without extra help. Can you give an example where this would break?
Or I'm partially wrong and it just requires some similar workaround to fix cxx support. It still would be nice to use pkgconfig instead of guesswork though. :)
Created attachment 390398 [details] build.log with cxx enabled It appears to fail due to libtool trying to relink on install when cxx support is enabled.
That is a different issue caused by libtool. We patch against this but only if you call elibtoolize. I have encountered this in a huge number of packages and it is practically impossible to monkey patch into Portage via bashrc or whatever, which makes it especially frustrating. I would like to have this handled automatically by Portage and I was going to raise the point once I became a dev, which shouldn't be far away now.
(In reply to James Le Cuirot from comment #5) > That is a different issue caused by libtool. We patch against this but only > if you call elibtoolize. Right, we are calling elibtoolize (via autotools-utils), but the fix-relink patch isn't getting applied for some reason. If we can figure that out, I'll fix things.
(In reply to Tim Harder from comment #6) > (In reply to James Le Cuirot from comment #5) > > That is a different issue caused by libtool. We patch against this but only > > if you call elibtoolize. > > Right, we are calling elibtoolize (via autotools-utils), but the fix-relink > patch isn't getting applied for some reason. If we can figure that out, I'll > fix things. I'm going to guess it's because we don't have a fix-relink patch written yet for newer libtool versions (since ltmain.sh from flac is 2.4.2), but I'm not very familiar with cross-compile libtool and libtool.eclass machinations.
Hmm I thought we were still patching this for recent libtool versions but I guess not. Maybe something else is going on here. I'll check it out later.
I've not been able to reproduce this. My cross-boss system takes several measures to avoid problems like this so I tried it with plain old armv7a-hardfloat-linux-gnueabi-emerge and I still couldn't reproduce it. The main difference I can see is that more patches get applied on my system. * Running elibtoolize in: flac-1.3.0/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying cross/link-ROOT patch ... * Applying as-needed/2.4.2 patch ... * Applying target-nm/2.4.2 patch ... Any idea why that might be?
(In reply to James Le Cuirot from comment #9) > I've not been able to reproduce this. My cross-boss system takes several > measures to avoid problems like this so I tried it with plain old > armv7a-hardfloat-linux-gnueabi-emerge and I still couldn't reproduce it. The > main difference I can see is that more patches get applied on my system. > > * Running elibtoolize in: flac-1.3.0/ > * Applying portage/1.2.0 patch ... > * Applying sed/1.5.6 patch ... > * Applying cross/link-ROOT patch ... > * Applying as-needed/2.4.2 patch ... > * Applying target-nm/2.4.2 patch ... > > Any idea why that might be? No idea off the top of my head. Anyway, I've committed this fix to the ebuild so this should work for you at least. :)
