From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25575 invoked by alias); 28 Feb 2013 18:25:43 -0000 Received: (qmail 25546 invoked by uid 22791); 28 Feb 2013 18:25:39 -0000 X-SWARE-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mailfront3.g2host.com (HELO g2host.com) (208.42.184.241) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Feb 2013 18:25:28 +0000 Received: from [70.89.199.234] (account christopherpb@voomtech.com HELO [192.168.1.211]) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPA id 99670081 for ecos-discuss@ecos.sourceware.org; Thu, 28 Feb 2013 12:25:26 -0600 Message-ID: <512FA115.4030808@voomtech.com> Date: Thu, 28 Feb 2013 18:25:00 -0000 From: Christopher Biessener User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ecos Discussion References: <51228FE9.1030605@voomtech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: migration from win2k to win7 X-SW-Source: 2013-02/txt/msg00033.txt.bz2 When I wrote my first treatise I was a 100% greenhorn when it came to eCos and cross-compilers. Now that I've had some time to do more digging/research, and with the hint provided by Mr. Edwards (thank you, btw) that I shouldn't have tried to link with a libgcc built for i686, I've taken a step or two forward in the Win7 build environment. In keeping with the mantra, "Change as little as possible," my first stab was to build my own toolchain since eCosCentric does not allow direct download of the toolchains they have built. I followed the instructions on http://ecos.sourceware.org/build-toolchain.html only updating the packages for gcc 4.5.3 (since Cygwin 1.7 comes with gcc 4.5.3). I downloaded: * binutils-2.22 * gcc-core-4.5.3 for almost * gcc-g++-4.5.3 * insight-6.1 * newlib-1.19.0 I have to admit I'm a little confused since the eCos.org instructions do not tell the user to do anything with insight or newlib after downloading them. Anyway, I followed the directions down to where I'm 'make'ing gcc. The front part of the make finds all the header files and succeeds. When it gets to libiberty the configure in that directory no longer finds the ANSI header files. That script expects to find them in /gnutools/include. This directory does not yet exist. The grand makefile for whatever reason has not created it yet. Why??? Why does a product that's existed for almost 2 years fail to build itself? In further reading of the eCos.ord website I saw that eCos3 will allow the download of the eCosCentric toolchains. So I cloned my Win7 drive, uninstalled eCos 1.3.1, then installed eCos 3.0. The eCos3 Configurator does not include our Atmel ARM7 processor. So I'm stuck. Please point me in the proper direction to continue making progress. Thank you, Christopher Biessener Voom Technologies, Inc. BTW, to answer Mr. Edwards question about the 4.6.0 toolchain, yes, Macraigor Systems makes the hardware/software we use to program our devices over the JTAG. On 02/18/2013 04:20 PM, Grant Edwards wrote: > On 2013-02-18, Christopher Biessener wrote: >> Hi all, >> >> I am new to embedded systems and got handed the task of migrating our >> build environment from win2k to win7. >> In win2k they are using Cygwin 1.3 / eCos 1.3.1 / gcc 2.95 toolchain. >> This setup compiles and links and our hardware runs beautifully. We >> can't keep limping along on win2k, however. > My advice would be to do your development on Linux. Even if you have > to run Linu in a VM under Win7, that's probably going to be easier in > the end than trying to use eCos that old building Cygwin. My > experience mixing and matching arbitrary versions of Windows, Cygwin, > toolchains and eCos have always been poor. Replacing Windows and > Cygwin with Linux always made things a lot simpler. >> The arm-elf 2.95 toolchain will not install in win7, so I began >> upgrading stuff. >> >> So far I have the newest Cygwin 1.7 - which uses gcc 4.5.3. I >> downloaded the arm-elf toolchain via MacCraigor Systems website which >> is gcc 4.6.0. > Is that a toolchain intended for use with eCos? Why not use the ARM > toolchain offered for download by eCosCentric? >> I cannot find the arm-elf toolchain in any other rev-level. >> Apparently eCos 1.3.1 is still viable and it did install on win7, so >> that is what I used. I am afraid of upgrading to eCos 3.0 because I >> have no idea what configuration options were used. There is no >> documentation the original developers left - and yes, they are long >> gone. >> >> At first gcc couldn't find libgcc, so I added >> -L/usr/lib/gcc/i686-pc-cygwin/4.5.3 to the link flags. > That's almost certainly incorrect. You can't use a libgcc for i686 if > you're compiling for an ARM target.Without further changing our makefiles everything compiled, but it > will not link. The following is part of the output of make: > > ---------------------- > arm-elf-gcc -mcpu=arm7tdmi -u cyg_user_start > -Wl,'-Map=HC3-P_Hw_Cf_P1.map' -nostartfiles -Wl,--gc-sections > -L./romram_install/lib -L/usr/lib/gcc/i686-pc-cygwin/4.5.3 -o > HC3-P_Hw_Cf_P1.elf libHC3-P_Hw_Cf_P1.a libromHC3-P_Hw_Cf_P1.a > -TtargetHC3-P_Hw_Cf_P1.ld -nostdlib > libromHC3-P_Hw_Cf_P1.a(HardCopy.o): In function > `__static_initialization_and_destruction_0(int, int)': > HardCopy.cpp:(.text._Z41__static_initialization_and_destruction_0ii+0x48): > undefined reference to `__cxa_atexit' > HardCopy.cpp:(.text._Z41__static_initialization_and_destruction_0ii+0x60): > undefined reference to `__dso_handle' > libromHC3-P_Hw_Cf_P1.a(fat32.o): In function > `CFAT32::InitBootSector(FAT32_BOOT_SECTOR*, FAT32_FSINFO_SECTOR*)': > fat32.cpp:(.text._ZN6CFAT3214InitBootSectorEP17FAT32_BOOT_SECTORP19FAT32_FSINFO_SECTOR+0x118): > undefined reference to `__umodsi3' > fat32.cpp:(.text._ZN6CFAT3214InitBootSectorEP17FAT32_BOOT_SECTORP19FAT32_FSINFO_SECTOR+0x150): > undefined reference to `__udivsi3' > ---------------------- > > Any suggestions would be greatly appreciated. I did begin by searching > the list archive. There were no solutions to be found. > > Thanks, > > Christopher Biessener > Voom Technologies, Inc. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss