This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: building old gcc3 for i386-linux on recent x86-linux?


On Sun, Feb 21, 2016 at 7:12 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> How to build a gcc3 host=x86-linux target=i386-old-linux today?
>
> The best way is to replicate the old development environment, perhaps
> using virtualization or emulation.

OK, for the time being, now I'm using a virtual box appliance.
This of course works.

> In general, there is no other way because GCC itself is not
> sufficient, you also need the old libraries to link to, in compatible
> versions.

Yes sure, of course! This is a main purpose of the planned toolchains.

On recent linux, as required by recent hardware (for example,
supporting 70 GB RAM), libs are usually advanced and even
language (C++) is. So when using a recent linux dev env, we would
need to port the applications to old versions, which is far away
from fun (developers don't like downgrading own code to old
libs), so I think it is essential to develop with no newer
version than needed. Also, we like to met as much bugs as
possible on our simulation environment, because it is easier to
debug than the embedded target.

> The old environment has all that, and is the simplest approach
> if some distribution-supplied environment was used in the first
> place.

The old environment has all that only because it has the
appropriate GNU cross compiling toolchain. So I think the idea to
run the same GNU cross compiling toolchain also on the new host
system. Well, and then I hope it should be easy to cross-compile
to the simulators (technically, VirtualBox hosts), too. Should be
same, except that not intel but powerpc.

For the long term, I'd like to compile for multiple targets on
the same compile farm servers.

> If not, it can be easier to patch the existing binaries to fix
> the bugs or add the missing functionality, depending on how
> complex the original environment was and how invasive the
> desired changes are.

I didn't understand this part. I see no resonable way to patch an
application binary, of course the source code must be changed and
recompiled?

Steffen


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]