G++ an multiple architectures (solved)

Matthew Gillen me at mattgillen.net
Thu Nov 16 10:04:36 EST 2006


Jerry Feldman wrote:
> On Tue, 14 Nov 2006 09:38:17 -0500
> Matthew Gillen <me at mattgillen.net> wrote:
> 
>> Jerry Feldman wrote:
>>> As I mentioned yesterday, the /usr/include/c++/3.4.3/x86_64-redhat-linux
>>> directory was missing. At the moment, I don't have the systems set up for 
>>> up2date, but my solution was to simply copy that directory tree from a 
>>> known good system. Apparently the libraries were fine, so it is simply the 
>>> c++ include files. I was able to compile both 64-bit and 32-bit c++ 
>>> programs aftrer I did that.
>> On the known-good system, you can do:
>>  rpm -q --whatprovides /usr/include/c++/3.4.3/x86_64-redhat-linux
>>
>> to find out what package you're missing on the broken system (libstdc++-devel
>> perhaps?).
>
> It does not show up. It does show up on the good system.

Right, I thought so.  I apologize for not finishing my thought in my original
post:
You are almost certainly better off installing the appropriate package on the
"bad" system.  Every single time I've tried copying a system directory tree
(ie some directory that is package-managed) from another machine, it's ended
up being more headache than it's worth.  I'm not suggesting using up2date,
since that will not install new packages.  I'm saying you should get the exact
version that's installed on the other system.

If you really, really don't want to "do the right thing", here's a few things
that you should do or keep in mind besides the fact that updating the "bad"
system will be a pain:
 - find any other files that libstdc++-devel installs (via 'rpm -ql
<pacakagename>' ) that aren't in the tree you manually copied over (for
example, -devel packages often install a symlink  to a library that's needed
for compile-time linking, but not run-time linking)
 - find any other packages that depend on libstdc++-devel (via 'rpm -q
--whatrequires libstdc++-devel'), and manually copy the files associated with
those packages.

It's certainly possible to bypass package management.  It's just more work and
more headaches in the long run.

That's my $0.02...
Matt

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the Discuss mailing list