o test the Arm
cross compiler? Are there any documents?
These days I'd be QEMU is the best approach if you don't have hardware.
Not sure if there's any reasonable documentation on it. The embecosm
folks might have suitable docs on their web page along with the dejagnu
configurat
To my surprise, I have just found out that Arm simulator has been
deprecated:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aec7815b4b78d4dcd2261f1dab1092dbf4a9e0be.
Taking that into account what is the "official" way to test the Arm
cross compiler? Are there any documents?
/J.D.
Am 27.09.2024 um 13:00 schrieb Richard Earnshaw (lists):
> It was very common at that time for suppliers to use slightly modified gcc
sources for microcontrollers (especially ARM, but also for other targets).
Typically manufacturers and some major third-party gcc builders were ahead of
mainli
Am 27.09.2024 um 11:03 schrieb David Brown:
So there is a very real chance that the sources you have are not original.
You could download the archived release from the gcc website and compare
the sources to get some idea if they have changed.
i do not have original source - only binaries, i ho
On 27/09/2024 10:03, David Brown via Gcc wrote:
> On 27/09/2024 10:13, Dennis Luehring via Gcc wrote:
>> Am 27.09.2024 um 09:56 schrieb Jonathan Wakely:
>>> On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote:
>>>
>>> > Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
>>> >
>>> >
>>> > > They might
On 27/09/2024 10:13, Dennis Luehring via Gcc wrote:
Am 27.09.2024 um 09:56 schrieb Jonathan Wakely:
On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote:
> Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
>
>
> > They might not have
> > been using the original gcc-3.4.0 sources.
>
>
> seems to be
On Fri, 27 Sept 2024 at 09:13, Dennis Luehring wrote:
>
> Am 27.09.2024 um 09:56 schrieb Jonathan Wakely:
> > On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote:
> >
> > > Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
> > >
> > >
> > > > They might not have
> > > > been using the original gcc-3
Am 27.09.2024 um 09:56 schrieb Jonathan Wakely:
On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote:
> Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
>
>
> > They might not have
> > been using the original gcc-3.4.0 sources.
>
>
> seems to be very possible
>
>
>
> > There should be no need to e
On Fri, 27 Sept 2024, 08:39 Dennis Luehring, wrote:
> Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
>
>
> > They might not have
> > been using the original gcc-3.4.0 sources.
>
>
> seems to be very possible
>
>
>
> > There should be no need to edit those files, but that doesn't mean that
> the
content of my gcc-3.4.0\gcc\config\arm\t-arm-elf
https://pastebin.com/CivYHhRa
Am 27.09.2024 um 09:23 schrieb Dennis Luehring via Gcc:
im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
old cross toolchain
building with my script (https://pastebin.com/kAEK0S24) works
but my
On Fri, 27 Sept 2024, 08:24 Dennis Luehring via Gcc,
wrote:
> im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
> old cross toolchain
> building with my script (https://pastebin.com/kAEK0S24) works
> but my -print-multi-lib returns only
>
> ---
> .;
> thumb;@mthumb
> ---
>
>
Am 27.09.2024 um 09:34 schrieb Jonathan Wakely:
They might not have
been using the original gcc-3.4.0 sources.
seems to be very possible
There should be no need to edit those files, but that doesn't mean that the
people who built your old toolchain didn't edit them.
the other way would
im currently trying to replicate a gcc-3.4.0 arm-elf build from an very
old cross toolchain
building with my script (https://pastebin.com/kAEK0S24) works
but my -print-multi-lib returns only
---
.;
thumb;@mthumb
---
the original builds -print-multi-lib returns
---
.;
thumb;@mthumb
be;@mbig-endi
On Tue, 8 Nov 2022 at 12:37, Jonathan Wakely wrote:
>
> On Tue, 8 Nov 2022 at 11:22, Florian Weimer via Libstdc++
> wrote:
> >
> > I'm trying to validate a change to gcc/config/msp430/msp430.cc.
> > The cross-compiler builds as far as I can tell, but I hit a sn
On Tue, 8 Nov 2022 at 11:22, Florian Weimer via Libstdc++
wrote:
>
> I'm trying to validate a change to gcc/config/msp430/msp430.cc.
> The cross-compiler builds as far as I can tell, but I hit a snag while
> configuring libstdc++:
>
> checking for shl_load... configure: er
I'm trying to validate a change to gcc/config/msp430/msp430.cc.
The cross-compiler builds as far as I can tell, but I hit a snag while
configuring libstdc++:
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:12334: conf
On 15/6/22 7:56 pm, Richard Biener wrote:
> On Wed, Jun 15, 2022 at 11:27 AM Chris Johns
> wrote:
>>
>> Hi,
>>
>> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
>> chip vendor is using it when building controller software tha
On Wed, Jun 15, 2022 at 11:27 AM Chris Johns wrote:
>
> Hi,
>
> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
> chip vendor is using it when building controller software that is part of a
> system.
>
> The build I am using symlinks gmp, mp
Hi,
I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
chip vendor is using it when building controller software that is part of a
system.
The build I am using symlinks gmp, mpfr etc as source so they are built as part
of the gcc build.
The mpfr package is reporting
On Nov 27 2019, Andrew Dean via gcc wrote:
> 2. export
> LD_LIBRARY_PATH=${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib64:${BuildRoot}/install/compilers/aarch64-linux-gnu/aarch64-glibc-linux-gnu/lib64
>
> 3. sudo ln -s
> ${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib/ld-linux-aarch64.so.
> On 11/25/19 2:43 PM, Andrew Dean via gcc wrote:
> >> I get errors like this:
> >>
> >> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> >> 'rdimon.specs': No such file or directory
> >>
> >> I can see that the rdimon.specs flag is added based on this lin
On 11/25/19 2:43 PM, Andrew Dean via gcc wrote:
>> I get errors like this:
>>
>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
>> 'rdimon.specs': No such file or directory
>>
>> I can see that the rdimon.specs flag is added based on this line
>> in aarc
On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean wrote:
>
> > > >>> I get errors like this:
> > > >>>
> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > > >>> 'rdimon.specs': No such file or directory
> > > >>>
> > > >>> I can see that the rdimon.specs flag is added based on
> > >>> I get errors like this:
> > >>>
> > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > >>> 'rdimon.specs': No such file or directory
> > >>>
> > >>> I can see that the rdimon.specs flag is added based on this line
> > >>> in aarch64-
> > >> sim.exp:
> > >>
> > >> Where
On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella
wrote:
>
>
>
> On 25/11/2019 17:28, Andrew Dean via gcc wrote:
> >>> This completes successfully. However, when I then try to run the gcc
> >>> tests like
> >> so:
> >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> >>> aarc
On 25/11/2019 17:28, Andrew Dean via gcc wrote:
>>> This completes successfully. However, when I then try to run the gcc tests
>>> like
>> so:
>>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
>>> aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
>>> --tool_e
> > This completes successfully. However, when I then try to run the gcc tests
> > like
> so:
> > runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> > aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
> > --tool_exec
> > /path_to/build_dir/install/compilers/aarch64
On Mon, 25 Nov 2019 at 20:17, Andrew Dean via gcc wrote:
>
> Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using
> glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:
>
> build-many-glibcs.py build_dir checkout --keep all
>
> build-many-glibcs.py build_dir host
Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using
glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:
build-many-glibcs.py build_dir checkout --keep all
build-many-glibcs.py build_dir host-libraries --keep all -j 12
build-many-glibcs.py build_dir compilers
(Please CC me as I am not subscribed)
It seems that when building a cross-compiler with a default --target but
no default --with-sysroot, the default -isystem =/usr/include path is
not automatically included when using --sysroot but default -L =/lib and
-L =/usr/lib are included.
(Full example
> On Aug 6, 2015, at 1:27 PM, Alan Lehotsky wrote:
>
> I have a funny situation where I’m trying to build a cross compiler for x86
> hosted on x86 where I’d like to use the native headers and libraries.
>
> I tried defining INCLUDE_DEFAULTS, and that didn’t help.
I have a funny situation where I’m trying to build a cross compiler for x86
hosted on x86 where I’d like to use the native headers and libraries.
I tried defining INCLUDE_DEFAULTS, and that didn’t help. The documentation
says it’s ignored for cross compilers.
Any suggestions, or am I going
Thank you Jonathan. I will followup in the help site.
On Fri, Jul 24, 2015 at 11:54 AM, Jonathan Wakely wrote:
> On 24 July 2015 at 18:31, sindhu selvam wrote:
>> /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find crti.o: No
>> such file or directory
>> /usr/local/cross/x86_64-pc-linux-gnu/
On 24 July 2015 at 18:31, sindhu selvam wrote:
> /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find crti.o: No
> such file or directory
> /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find -lc
> /usr/local/cross/x86_64-pc-linux-gnu/bin/ld: cannot find crtn.o: No
> such file or directory
I am trying to build a GCC (version 4.9.3)cross compiler on my windows
machine using Cygwin. I am using the source package that came along
with cygwin.
I have already built binutils version 2.25 and installed, this is
through cygwin as well.
binutils configuration used:
../binutils-x.y.z
Dear GCC Team,
I would like to report that cross-compiler GCC 4.8.3 for AArch64 port
(aarch64-linux-gnu) is successfully built and installed on Ubuntu 12.04.3 LTS
Buildstat Info:
user1@linux:~/aarch64-crossbuild-gcc4.8.3/gcc/gcc-4.8.3$ ./config.guess
i686-pc-linux-gnu
user1@linux:~/aarch64
I am looking at how to best integrate building a cross compiler in our
source tree, which is a little bit old-baken and easy to break.
Nevertheless, I'd like to to it like you're supposed to do with new
GCC's. I am using 4.8.1 now. Rather than describing my specific
problem,
> Ok, I will do a full build tonight with the testuite and take this "test
> $build = $target" out of the build. I can only do a x86_64 linux test,
> should I send the results to the list?
You obviously need to test on a configuration that exercises the path.
--
Eric Botcazou
On Wed, 2013-01-09 at 08:43 +, Luke A. Guest wrote:
> 1) The latest problem I'm having is that it fails to build
> libgnat-4.6.so, I've managed to track it down to the following code
> inside libada/configure:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>
On Wed, 2013-01-09 at 09:57 +0100, Arnaud Charlet wrote:
> > 2) I also want to point out that inside
> > gcc/ada/gcc-interface/Makefile.in there are lines such as:
> >
> > GNATLIB_SHARED = gnatlib-shared-dual
> >
> > Is these relics?
>
> No, these are correct settings. If there's a mistake,
> 1) The latest problem I'm having is that it fails to build
> libgnat-4.6.so, I've managed to track it down to the following code
> inside libada/configure:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
> # No
On Wed, Jan 09, 2013 at 08:43:11AM +, Luke A. Guest wrote:
> Hi,
>
> I'm trying to add GNAT to Yocto and still coming across problems. I have
> a number of questions about GNAT as a cross compiler, I know it wasn't
> designed as one within the GCC tree, but I think it
Hi,
I'm trying to add GNAT to Yocto and still coming across problems. I have
a number of questions about GNAT as a cross compiler, I know it wasn't
designed as one within the GCC tree, but I think it needs to be capable
of building as one to match the other compilers.
1) The latest p
hether host != target,
but whether build != target. Actually you may want to know whether
the compiler produces executables that run on the build system, but
that is more complicated still--e.g., a cross-compiler from x86_64 to
i386 GNU/Linux can produce executables that run on the build system
even
Hello All,
What is the simplest way, for a plugin (and also for a GCC branch),
to detect if the compiler is straight or not (i.e. cross, that is
target & host are different, or even canadian-cross).
I was thinking of some macro in auto-host.h or other header.
(MELT is, during its building proc
On 03/30/2012 05:46 PM, stuart wrote:
> I can not seem to get gcc 4.7.0 to compile; it will not complete the
> configuration stage complaining about missing packages (GMP, MPFR and
> MPC).
Go into the top-level source directory in the unpacked gcc sources
and run this script:
./contrib/download_
stuart writes:
> I am not sure this is the right place to ask this
It's not. The right place is gcc-h...@gcc.gnu.org. Please take any
followups there. Thanks.
> I can not seem to get gcc 4.7.0 to compile; it will not complete the
> configuration stage complaining about missing packages (GMP
Hi,
I am not sure this is the right place to ask this, but how do I get gcc
4.7.0 to compile as a cross compiler for the Atmel AVR series?
The native host is an x86 IA32 box running Slackware, gcc 3.3.6.
I have successfully compiled and installed (in /usr/local/avr) binutils
2.22 and set my
I need to install gcc cross compiler into Ubuntu 11.10 operating
> system on Intel core2due.
A cross compiler for what architecture? I think Ubuntu includes an
arm cross compiler, if that's what you want then you should install it
from the Ubuntu package manager.
Hi
apologize for interrupt and weak English.
I need to install gcc cross compiler into Ubuntu 11.10 operating
system on Intel core2due.
--
Best
Esmaeil
https://sites.google.com/site/esmaeilmirzaee
Anthony Foiani writes:
> Is there any particular reason that you're not taking advantage of the
> many person-years of effort that have been put into tools that do
> exactly this?
It's been pointed out to me that Khem very much knows of crosstool and
its ilk, being a committer of some standing.
Khem Raj writes:
> I a script based on these instructions which is uptodate and builds eglibc
> based toolchains
>
> https://github.com/kraj/ct-scripts/blob/master/toolchain-eglibc.sh
Is there any particular reason that you're not taking advantage of the
many person-years of effort that have been
On Mon, Jul 18, 2011 at 8:10 PM, Khem Raj wrote:
> On Mon, Jul 18, 2011 at 4:58 AM, Rohit Arul Raj
> wrote:
>>
>> Is this expected behavior?
>>
>>
> yes
>
Hello Khem,
1. Got in to another error while doing make [make csu/subdir_lib] of
"eglibc default headers"..
nux-gnu/tools/lib/gcc/powerpc-
On Mon, Jul 18, 2011 at 4:58 AM, Rohit Arul Raj wrote:
>
> Is this expected behavior?
>
>
yes
On Fri, Jul 8, 2011 at 8:03 PM, Khem Raj wrote:
> On Fri, Jul 8, 2011 at 1:08 AM, Rohit Arul Raj wrote:
>> On Wed, Mar 23, 2011 at 5:55 PM, Joseph S. Myers
>> wrote:
>>> On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
>>>
>>>> Hello All,
>>>&g
On Fri, Jul 8, 2011 at 1:08 AM, Rohit Arul Raj wrote:
> On Wed, Mar 23, 2011 at 5:55 PM, Joseph S. Myers
> wrote:
>> On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
>>
>>> Hello All,
>>>
>>> I have been trying to build a cross compiler (for PowerPC) o
On Fri, 8 Jul 2011, Rohit Arul Raj wrote:
> Adding "--disable-decimal-float --disable-libffi
> --disable-libquadmath" to configure options gives the same error.
Then you must debug the issue yourself, on the system you are using for
building, and gain sufficient understanding of the code in the
Rohit Arul Raj writes:
> Any updates on this one yet?
> Adding "--disable-decimal-float --disable-libffi
> --disable-libquadmath" to configure options gives the same error.
It is much easier to bootstrap with some previous glibc build (any one
will do) already in sysroot.
Andreas.
--
Andreas
On Wed, Mar 23, 2011 at 5:55 PM, Joseph S. Myers
wrote:
> On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
>
>> Hello All,
>>
>> I have been trying to build a cross compiler (for PowerPC) on x86_64
>> linux host. I followed the build procedure given in the link belo
On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
> Hello All,
>
> I have been trying to build a cross compiler (for PowerPC) on x86_64
> linux host. I followed the build procedure given in the link below:
>
> http://www.eglibc.org/archives/patches/msg00078.html
You should be referr
Hello All,
I have been trying to build a cross compiler (for PowerPC) on x86_64
linux host. I followed the build procedure given in the link below:
http://www.eglibc.org/archives/patches/msg00078.html
The build instructions in the link works perfectly fine with the
following revisions:
GCC
> Can you point me at least to the section which explains this?
http://gcc.gnu.org/install/build.html
--
Eric Botcazou
On Tue, 2011-02-01 at 18:57 +0100, Arnaud Charlet wrote:
> > I'm trying (again) to work out how to build a GNAT cross compiler with
> > no runtime, but with the tools.
>
> As explained in the documentation, you need to first build a native GNAT
> compiler with the same
> I'm trying (again) to work out how to build a GNAT cross compiler with
> no runtime, but with the tools.
As explained in the documentation, you need to first build a native GNAT
compiler with the same sources before building a GNAT cross compiler.
Arno
Hi,
I'm trying (again) to work out how to build a GNAT cross compiler with
no runtime, but with the tools.
Firstly, I'd just like to ask, is this supposed to be possible?
If it is possible, why is it so hard/impossible and why will nobody from
AdaCore answer my questions regardin
The error is also reproduced with gcc 4.5 revision 153504
t; wrong but I don't know what it is.
I have successfully build cross-compiler with overriden RPATH_ENVVAR,
as following:
make RPATH_ENVVAR=MY_LD_LIBRARY_PATH
So error was indeed caused by changing LD_LIBRARY_PATH during the
build, as described by Kai.
I think this is a bug.
Denis Onischenko writes:
> I am getting the following error when compiling "x86_64 to powerpc64"
> cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc
> directory.
This question would be more appropriate for the mailing list
gcc-h...@gcc.gnu.org. Please take any followups there. Th
I am getting the following error when compiling "x86_64 to powerpc64"
cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc
directory.
...
# Now that we have built all the objects, we need to copy
# them back to the GCC directory. Too many things (other
# in-tree libraries, and DejaGNU
On Mon, 23 Mar 2009 18:51:50 +, Dave Korn
wrote:
> Vincent R. wrote:
>
>> vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps
>> -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c
>> -DDLL_EXPORT -DPIC -o libeet_la-eet_lib.o
>> cegcc-errno-bug.c: In fun
Vincent R. wrote:
> vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps
> -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c
> -DDLL_EXPORT -DPIC -o libeet_la-eet_lib.o
> cegcc-errno-bug.c: In function 'eet_close':
> cegcc-errno-bug.c:134: error: unrecogniza
Hi,
I am testing a cross-compiler targetting arm-wince-pe and based on
gcc-trunk revision r144975 and when
compiling a project I get the following error :
vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps
-I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kai Ruottu schrieb:
> Rainer Emrich wrote:
>>> Maybe putting only
>>> the bare 'milli.a' there, assuming a '-L/usr/lib/pa20_64' in the
>>> native case and a '-L$sysroot/usr/lib/pa20_64' in the cross case,
>>> on the link command line, could be the requ
This is a bug in gcc.
The string is hard coded in: gcc/config/pa/pa64-hpux.h
/* The libgcc_stub.a and milli.a libraries need to come last. */
#undef LINK_GCC_C_SEQUENCE_SPEC
#define LINK_GCC_C_SEQUENCE_SPEC "\
%G %L %G %{!nostdlib:%{!nodefaultlibs:%{!shared:-lgcc_stub}\
/usr/lib/pa20_64/mill
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kai Ruottu schrieb:
> Rainer Emrich wrote:
>
>>>> I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
>>>> hppa64-hp-hpux11.00 using gcc trunk.
>> I run into the next issue.
>>
>
Kai Ruottu wrote:
Rainer Emrich wrote:
I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
hppa64-hp-hpux11.00 using gcc trunk.
I run into the next issue.
/usr/lib/pa20_64/milli.a is tried to be linked directly instead be
searched in the sysroot.
- --with-sysroot=/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Andrew,
I try to explain from the beginning.
The original problem:
-
checking for pid_t... yes
checking for library containing strerror... configure: error: Link te
Rainer Emrich wrote:
I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
hppa64-hp-hpux11.00 using gcc trunk.
I run into the next issue.
/usr/lib/pa20_64/milli.a is tried to be linked directly instead be searched in
the sysroot.
- --with-sysroot=/opt/tec/setup/sys-r
Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew, thanks for your quick reply.
>
> Andrew Haley schrieb:
>> Rainer Emrich wrote:
>>
>>> I try to build a cross compiler host x86_64-unknown-linux-gnu -> targ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew, thanks for your quick reply.
Andrew Haley schrieb:
> Rainer Emrich wrote:
>
>> I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
>> hppa64-hp-hpux11.00 using gcc trunk.
>>
>> Everything
Rainer Emrich wrote:
> I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
> hppa64-hp-hpux11.00 using gcc trunk.
>
> Everything wents fine until building of the libraries.
> libssp is build, but libiberty fails in the configure step:
>
> checkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I try to build a cross compiler host x86_64-unknown-linux-gnu -> target
hppa64-hp-hpux11.00 using gcc trunk.
Everything wents fine until building of the libraries.
libssp is build, but libiberty fails in the configure step:
checking for sys/type
Ioannis, all,
On Tuesday 24 June 2008 20:50:11 [EMAIL PROTECTED] wrote:
> > I am trying to build a cross-compiler for an alphaev56-unknown-linux-gnu
> > system, using crosstool-ng. The host is a i686-unknown-linux-gnu.
[--SNIP--]
> > I managed to get as far as descri
Hello again,
Does no one have any idea about the problem I described in my previous
message? Do you need more information to check it? If so, let me know.
Thanks!
Ioannis
Dear all,
I am trying to build a cross-compiler for an alphaev56-unknown-linux-gnu
system, using crosstool-ng. The host is a i686-unknown-linux-gnu.
After applying several patches (look in [1]), I managed to build a
tool-chain using binutils 2.18/gcc 4.2.3/linux kernel 2.6.24.7 and glibc
2.3.6
> I am running into a problem when I am trying to compile GCC to run on
> a i686-pc-linux-gnu (host) but to build source code for target,
> x86_64-pc-linux-gnu. I have build binutils first with the following
> configure parameters:
> --enable-plugin --with-cpu=generic --host=x86_64-pc-linux-gnu
-- Forwarded message --
From: NoFirst NoLast <[EMAIL PROTECTED]>
Date: Mon, Apr 28, 2008 at 6:46 PM
Subject: gcc cross compiler problem
To: gcc@gcc.gnu.org
Hello gcc,
I am running into a problem when I am trying to compile GCC to run on
a i686-pc-linux-gnu (host) but to
Hi,
I am using latest cygwin to build cross gcc for linux. I am using
crosstool-0.43 with demo-i686.sh modified to have as given below. I
dont know if I am right in this config. or any this else is need, but
build stop with attached error. I have also posted the question in
crossgcc group.
As see
Schipper, K. - SPLXM writes:
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee
> > only. If you are not the addressee, you are notified tha
Schipper, K. - SPLXM writes:
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no par
Hi, I have a question. We are in the process of building a cross
compiler for our system on Linux.
In the documentation I read that we need the GPL file:
"gpl-include.tar.bz2"
Do you perhaps know where this file can be obtained so that we can
proceed with our build?
Best regards,
Kee
Stephen,
I have been working on the x86_64-pc-mingw32 toolchain with Kai Tietz
(Kai is the main person, I am doing much more learning than helping).
I put together a built script that requires no tweaking whatsoever of
any of the projects incorporated in the toolchain. It is very
straightforward.
On 9/11/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote:
>You shouldn't define them, they'll only hide the problem.
You're right, and getting REG_OK_STRICT right solved the problem!
That was probably the best answer I ha
On Tue, Sep 11, 2007 at 08:52:38AM +0200, Tomas Svensson wrote:
> Thanks a lot for your input, I think I understand some of that code better
> now.
>
> I stumbled upon a solution last night, on realizing that the problem
> was with the DFmode powidf2 and seeing that I had not defined the
> movsf
Thanks a lot for your input, I think I understand some of that code better now.
I stumbled upon a solution last night, on realizing that the problem
was with the DFmode powidf2 and seeing that I had not defined the
movsf or movdf insns (because I thought I shouldn't need them, having
no HW floatin
On Mon, Sep 10, 2007 at 12:22:11PM +0200, Tomas Svensson wrote:
> static bool
> legitimate_offset_address_p (enum machine_mode mode ATTRIBUTE_UNUSED, rtx
> addr)
> {
> rtx reg, offset;
>
> if (GET_CODE (addr) != PLUS)
> return false;
>
> reg = XEXP (addr, 0);
> offset = XEXP (addr,
Tomas Svensson wrote:
It seems that gcc has emitted rtl describing a memory reference (mem
(plus (mem (plus (reg ..) (const_int ..))) (const_int ..))), which
should not have been permitted by GO_IF_LEGITIMATE_ADDRESS since it
only allows (mem (plus (reg ..) (const ..))), and forbids a second
leve
On 9/10/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote:
>It would help a lot if you post your GO_IF_LEGITIMATE_ADDRESS.
It's really very basic:
# define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
{ if (legitimate_address_p (MODE, X, true)) goto ADDR; }
and in the .c-file:
bool
le
On Mon, Sep 10, 2007 at 09:54:57AM +0200, Tomas Svensson wrote:
>
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c: In function '__powidf2':
> /cygdrive/c/home/risc/src/gcc-4.1.2/gcc/libgcc2.c:1559: error: insn
> does not satisfy its constraints:
> (insn 114 153 117
> /cygdrive/c/home/risc/src/
On 10 September 2007 08:55, Tomas Svensson wrote:
> I am porting gcc to a new target architecture, and have come across a
> problem when the make process tries to compile libgcc. The error I get
> is included below.
>
> It seems that gcc has emitted rtl describing a memory reference (mem
> (plus
1 - 100 of 222 matches
Mail list logo
