Taj Morton wrote:
> I was hoping for a solution that maybe involved sedding the libtool file, or
> something like that. If I can't acomplish it that was, I guess I can just
> modify
> Autopackage's wrapper around gcc/g++ to link the compilers libstdc++.so.
Can't you just build+install a private
On Mon, 09 Oct 2006 12:36:47 -0400, Mike Frysinger wrote:
> what you want to do just wont work regardless of the issue you raise below
> ...
> gcc 3.3 and gcc 3.4 have incompatible ABI's so you cannot mix things built
> with the two compilers as you'll just end up with some things using
> libst
Ralf Wildenhues gmx.de> writes:
>
> * Taj Morton wrote on Wed, Oct 11, 2006 at 12:43:36AM CEST:
> > My problem is that when I compile my GCC-3.3 RPM, libtool links
> > against /usr/lib/libstdc++.so, instead of /opt/gcc-3.3/lib/libstdc++.so.
>
> Yes, you already wrote that. And I already told yo
Bruno Haible <[EMAIL PROTECTED]> writes:
> I wish to export the symbols of external{i}.c without modifications,
> whereas the symbols of internal{j}.c should get a prefix.
Doesn't the question of whether a symbol should get a prefix more
properly belong to .h files than to .c files? That is, if
Hello Jaimon,
* Jaimon Jose wrote on Wed, Oct 11, 2006 at 09:01:18AM CEST:
> Ralf Wildenhues wrote the following on 10/11/2006 02:59 AM:
> > Please resend your proposed changes in a unified diff format (diff -u),
> > that makes it easier to look at them, and safer.
> This is the proposed change in
Ralf Wildenhues wrote on 2006-09-08:
> > > are you planning on providing a means to
> > > automatically rename gnulib functions to a library-specific namespace?
> > > As long as there is no policy on interface stability for gnulib, I would
> > > fear to see lots of libraries floating around that al
