This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Kai, I really appreciate the guidance/feebacks given by you. I have finally successfully build the 'arm-linux' tool chain over MinGW. I am using GCC-3.2.2. I am using Glibc-2.2.3. The executable 'tst_arm-linux-gx' given by you doesn't work on my target probably becuase my Glibc is older than what you have used to build this executable. I have still some concerns about the tool chain: 1) $arm-linux-gcc test.c -o myout $arm-linux-readelf -l myout It says... Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00008034 0x00008034 0x000c0 0x000c0 R E 0x4 INTERP 0x0000f4 0x000080f4 0x000080f4 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x00008000 0x00008000 0x004ec 0x004ec R E 0x8000 LOAD 0x0004ec 0x000104ec 0x000104ec 0x00110 0x0012c RW 0x8000 BUT WHEN I DO $arm-linux-gcc -c test.c $arm-linux-ld test.o -o muout <crt*.o> $arm-linux-readelf -l myout It says... Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00008034 0x00008034 0x000c0 0x000c0 R E 0x4 INTERP 0x0000f4 0x000080f4 0x000080f4 0x00013 0x00013 R 0x1 [Requesting program interpreter: /usr/lib/ld.so.1] LOAD 0x000000 0x00008000 0x00008000 0x004ec 0x004ec R E 0x8000 LOAD 0x0004ec 0x000104ec 0x000104ec 0x00110 0x0012c RW 0x8000 WHY THERE IS THIS DIFFERENCE OF [Requesting program interpreter: xxxxxxx] My Specs reads like: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} -m armelf_linux -p Regards, Manoj > -----Original Message----- > From: Kai Ruottu [mailto:kai_ruottu@mbnet.fi] > Sent: Tuesday, November 18, 2003 7:41 PM > To: Manoj Verma, Noida > Subject: RE: Crosstool chain on MinGW > > > "Manoj Verma, Noida" <manojv@noida.hcltech.com> wrote: > > > By making the entry of ld-linux.so.2 in 'libc.so' script as, > > GROUP ( libc.so.6 ld-linux.so.2 libc_nonshared.a ) > > > > The linking errors are gone. > > > > But, when I try to execute the generated image on the > target it says: > > bash: ./myExe no such file and directory. > > > > On doing "readelf" over this image it reveals the following > statement in the > > "Program header" section: > > "[Requesting program interpreter: /usr/lib/ld.so.1]" > > > > On my target board there is no such file in the required path. > > So I copied the ld-2.2.3.so to /usr/lib/directory and > created ld.so.1 as a > > softlink to the ld-2.2.3.so. > > The 'ld.so.1' and 'ld-linux.so.2' are two names for just the same > thing. Earlier it could have been named as 'ld.so.1', this is the SVR4 > name for it, but most Linuces should now use the 'ld-linux.so.2', also > the ARM-one. Some like PPC, MIPS,... still use the SVR4 name for > some peculiar reason, or their developers don't yet think that they > should be afraid of SCO/Caldera accusing them for direct copying... > > BTW, the 'http://www.caldera.com/developers/devspecs' has > those SVR4 ABI docs for generic SVR4 and the i386 plus MIPS > Supplements in PDF format... > > A 'readelf -l' from an executable produced by my 'arm-linux-gnu' > target toolchain gives: > > Elf file type is EXEC (Executable file) > Entry point 0x200058c > There are 6 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg > Align > PHDR 0x000034 0x02000034 0x02000034 0x000c0 > 0x000c0 R E 0x4 > INTERP 0x0000f4 0x020000f4 0x020000f4 0x00013 0x00013 > R 0x1 > [Requesting program interpreter: /lib/ld-linux.so.2] > LOAD 0x000000 0x02000000 0x02000000 0x015d3 > 0x015d3 R E 0x8000 > LOAD 0x0015d4 0x020095d4 0x020095d4 0x00138 > 0x0013c RW 0x8000 > DYNAMIC 0x00167c 0x0200967c 0x0200967c 0x00090 > 0x00090 RW 0x4 > NOTE 0x000110 0x02000110 0x02000110 0x00020 > 0x00020 R 0x10 > > So the '/lib/ld-linux.so.2' is listed here and my 'link spec' for > gcc-2.95.3 tells too : > > *link: > %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} > %{shared:-shared} %{symbolic:-Bsymbolic} > %{rdynamic:-export-dynamic} > %{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2} <----- !! > -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} > %{!mapcs-26:-m armelf_linux} -p > > Why your GCC now uses a wrong name in its 'specs' is weird, > none of my 2.9 branch old sources didn't use this name. Maybe > you should check your GCC sources and the > gcc/config/arm/linux-elf.h > there for the '-dynamic-linker' name... > > > Now when I execute my program, it says segmentation fault. > > Does that mean, my tool chain is not built properly? If not what > > could be the reason? > > What is the: > > 1. Glibc used in the cross-toolchain ? > > 2. Glibc used in the target system ? > > Of course these should be just the same or the glibc on the target > system being newer, so trusting in 'backwards compatability', that > older binaries will run on newer systems, like binaries for Win98 > running on Win2k or on WinXP, or binaries for RedHat Linux 6.2 > running on RedHat Linux 7.3 ... > > In your case using a different glibc in the crosstools than on the > target system shouldn't have any reason, unless you have several > different target systems with different glibcs on them.... When one > builds crosstools for a target system, the aim usually is to produce > stuff for the target system (or for its newer versions), so for RedHat > 6.2 one uses RedHat 6.2 libraries, but the produced executables > should also run on RedHat 7.x, 8.x and 9.x... So the 'least common > nominator' (the oldest) among the target systems is the usual > choice for the chosen 'target'. > > If the glibc used in the crosstools is newer than the one used in the > target system, that could cause the produced executables crashing... > > > Yes, it picks up the Native as. I have tried giving the > --with-as=$TARGET-as > > gcc configure option. The problem persists. > > How do I make $TARGET-gcc to pick the $TARGET-as? > > Generally the directories seen for 'programs' in the: > > $TARGET-gcc -print-search-dirs > > output will be searched for 'as' and 'ld', unless there is a > bug in the > GCC sources -- the 'relative search paths' (the '../../../..' > ones) don't > work before the '$prefix/lib/gcc-lib/$target/$gcc-version' in > the search > paths exists. "Richard the Lionheart couldn't go via New Yourk to > Palestine, only via York". This bug was present in gcc-2.95.2 and > precreating the required 'install' directory was the workaround. > When building GCC, the install dirs didn't yet exist and so 'as' and > 'ld' were not found although they were where they should be.. > > I have attached that 'tst_arm-linux-gx' (produced using '-g') > executable for which that 'objdump -l' was used... It is a > 'test tprintf' test for glibc, giving quite a lot output, if > it works... > My MinGW-hosted glibc for arm-linux-gnu is from Dec. 2000, > maybe '2.2.5', but maybe older... If you could check if it runs > on your Linux/ARM system, that could be nice... > > Cheers, Kai > > ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |