Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

G++ an multiple architectures (solved)



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.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org