I've read a number of articles on that issue. Seems the consensus is that
i686 can cause problems. I thought that designation was originally made when
the pentium pros came out. But if have athlons, etc, you need to stay with
i586. Also seen that if you change the .LPR0 to LPRO or change to .glbl
.LPR0 in the code you can avoid the .LPR0 issue. Any coders following this
trail?

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of J.A. Magallon
Sent: Monday, October 02, 2000 6:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [expert] What is LPRO?


Praedor Tempus said at �Re: [expert] What is LPRO?�.
[2000-10-02 03:52]

> Bill Piety wrote:
> >
> > Praedor Tempus wrote:
> >
> > > Hello,
> > >
> > > Here is one such message I typically get when I try to run any kde app
> > > (from xterm):
> > >
> > > ** WARNING **: Unable to find handler for file:
> > > /usr/share/icons/large/sketch.xpm
> > > kcontrol: error in loading shared libraries: /usr/lib/libkdecore.so.2:
> > > undefined symbol: .LPR0

I had that problem when trying to compile any C++ code with the -march=i686
option
to gcc-2.95.2. It compiles fine with C (I build my 2.2.18-preX kernels with
-O4
-march=i686, and nvidia drivers with -O6 -march=i686), and C++ works fine
with
-march=i586. I think it is something related with the i686 code generation
in g++,
if you select i686 code there is some symbol output that must be present in
libstdc++, and is not there because libstdc++ is i586.

I returned to build everything in i586 conventions, because I have not
tested
seriously if the difference matters...

NOTE: g++ packagers, any help ?

Hope this gives any clue...




Keep in touch with http://mandrakeforum.com: 
Subscribe the "[EMAIL PROTECTED]" mailing list.

Reply via email to