Let me know what you find out regarding the g++ install
Turns out it was just a problem I had been having with 'update' for a while. Some of the downloads would fail with "Encountered a section with no Package: header" or various other errors.
According to what I had googled, the solution that should have worked was:
sudo rm /var/lib/apt/lists/* -vf
sudo apt-get update
But that always resulted in the same (or similar) failures during sudo apt-get update.
Today, after running that 'rm' command, I took a look to see what was in /var/lib/apt/lists, and there was a 'partial' directory, which I renamed to 'partial_hidden'.
Then, when I ran the sudo apt-get update it all went smoothly and I was subsequently able to run sudo apt-get install g++.
And Inline-CPP-0.45 now builds fine on the ubuntu box.
The problem on the debian box is a little different. On that box, I can run gcc in either 32-bit mode or 64-bit mode (-m32 or -m64).
But I can run g++ only in 32-bit mode. If I attempt to run it in 64-bit mode (g++ -m64) I'm told that the only exisitng libstdc++ it can find is incompatible.
So ... I figure I need to find out how to install the 64-bit libstdc++.
I've had a bit of a google around, but haven't yet found out how to do that.
Geez ... and people call MS Windows arcane !!
(Btw, Inline-CPP-0.45 builds and tests fine on the 32-bit perl on that deb box.)
Cheers,
Rob | [reply]
[d/l]
[select] |
I do recall a few times were apt-get gets out of whack and needs some manual cleanup before it will proceed with trouble-free installs. It doesn't matter what's being installed; if apt-get's database (if you can call it that) is messed up, nothing works right until it's reset.
Your explanation of the 32/64 bit libstdc++ issue might be a good catch. I think that the FAILs I see could be related to the same issue you're seeing on the deb box. It seems possible some people have 64 bit Perl builds, and only a 32-bit libstdc++. That's at least as good an explanation as I can come up with; I know Inline::CPP works on run-of-the-mill Linux systems. And there seems to be no obvious trend in the FAIL reports.
If you do figure that aspect out, let me know how you fixed it. I might start a TROUBLESHOOTING section in Inline::CPP's POD for such issues.
Now for my Windows jab; I once somehow got the Windows installer service's database wonky. I think a .NET upgrade failed partway through back when I was doing some MSVC++ work. It hung the system, and required a restart. From that point on, I wasn't able to install or upgrade anything, and couldn't find anything online to explain what needed to happen. Even rolling back to an earlier restore point didn't resolve the problem. Ultimately I had to restore the system to its factory-fresh state. Now that I think back on it, fixing apt-get turned out to be a much simpler process. ;)
| [reply]
[d/l] |
| [reply] |
It seems possible some people have 64 bit Perl builds, and only a 32-bit libstdc++
That does indeed seem possible. And if the test executable (that the Makefile.PL runs) fails to build, then the assumption is made that iostream is unavailable.
But, of course, that is not necessarily so. It could also be that the failure has occurred because there is no libstdc++ for the g++ compiler that has been chosen.
I suggest the Makefile.PL could first run this test script:
int main(void) {
return 0;
}
AFAICT, if that test script builds ok, then you know a suitable libstdc++ for the chosen g++ compiler has been found.
Once it is established that libstdc++ has been found, *then* you do the test to determine whether iostream is present.
As you know, just because there's a suitable libstdc++ for the chosen compiler doesn't necessarily mean that's the right g++ compiler for that build of perl.
But knowing that there's at least a libstdc++ for the compiler that was chosen might help narrow things down for you.
Still trying to find something that tells me how to run g++ in 64-bit mode on my deb box :-(
Cheers,
Rob | [reply]
[d/l] |
