From: Earnie B. <ear...@ya...> - 2002-05-28 21:23:53
|
Steven Edwards wrote: > > Hola, > I used the package you told me to download and I have only one minor > problem. When I extract it to the root of my mingw install D:\mingw > bison seems to work fine but when I try to really use it I get this: > > bison -y -d -t ./mcy.y > D:\mingw\bin\bison.exe: cannot open file `D:\mingw\bin\bison.simple': No > such file or directory > > I just copyed the /share/bison.simple and bison.hairy to /bin and it > worked fine. Like I said nothing major. > That's strange. Oh, probably not that strange, it has to do with /mingw/share/... not being resolved within bison. I'll have to take a look at the source for this. The other solution could have been export BISON_SIMPLE=D:/mingw/share/bison.simple export BISON_HAIRY=D:/mingw/share/bison.hairy > I will most likely have more bugs to share soon =P Thanks, Earnie. |
From: Greg C. <chi...@mi...> - 2002-11-13 19:32:36
|
Earnie Boyd wrote several months ago: > Subject: [Mingw-users] Re: Using MSYS/Mingw to port wine > Date: Tue, 28 May 2002 17:21:31 -0400 > > Steven Edwards wrote: > > > > I just copyed the /share/bison.simple and bison.hairy to /bin and it > > worked fine. Like I said nothing major. > > That's strange. Oh, probably not that strange, it has to do with > /mingw/share/... not being resolved within bison. I'll have to take a > look at the source for this. The other solution could have been > export BISON_SIMPLE=D:/mingw/share/bison.simple > export BISON_HAIRY=D:/mingw/share/bison.hairy Has the "/mingw/share/... not being resolved within bison" situation changed? I have: MSYS-1.0.8-i686-2002.06.25-1.exe latest snapshot is: MSYS-1.0.8-2002.09.07-1.exe Steven's fix works for me. I know I could set environment variables too. But I'm trying to write up procedures for others to use, and if this just works effortlessly in a later release with neither of those workarounds, then it's one less thing to document. |
From: Luke D. <cod...@ho...> - 2002-11-14 01:39:00
|
----- Original Message ----- From: "Greg Chicares" <chi...@mi...> To: "mingw-users" <min...@li...> Sent: Thursday, November 14, 2002 3:32 AM Subject: [Mingw-users] Configuring mingwDTK bison > Earnie Boyd wrote several months ago: > > Subject: [Mingw-users] Re: Using MSYS/Mingw to port wine > > Date: Tue, 28 May 2002 17:21:31 -0400 > > > > Steven Edwards wrote: > > > > > > I just copyed the /share/bison.simple and bison.hairy to /bin and it > > > worked fine. Like I said nothing major. > > > > That's strange. Oh, probably not that strange, it has to do with > > /mingw/share/... not being resolved within bison. I'll have to take a > > look at the source for this. The other solution could have been > > export BISON_SIMPLE=D:/mingw/share/bison.simple > > export BISON_HAIRY=D:/mingw/share/bison.hairy > > Has the "/mingw/share/... not being resolved within bison" > situation changed? > > I have: MSYS-1.0.8-i686-2002.06.25-1.exe > latest snapshot is: MSYS-1.0.8-2002.09.07-1.exe > > Steven's fix works for me. I know I could set environment > variables too. But I'm trying to write up procedures for > others to use, and if this just works effortlessly in a > later release with neither of those workarounds, then > it's one less thing to document. The gnuwin32 port of bison has been patched to look for data files relative to the bin directory, so using the binary distribution of that package is probably the simplest solution. Luke |
From: Greg C. <chi...@mi...> - 2002-11-14 05:54:42
|
Luke Dunstan wrote: > > ----- Original Message ----- > From: "Greg Chicares" <chi...@mi...> > To: "mingw-users" <min...@li...> > Sent: Thursday, November 14, 2002 3:32 AM > Subject: [Mingw-users] Configuring mingwDTK bison > > > Earnie Boyd wrote several months ago: > > > Subject: [Mingw-users] Re: Using MSYS/Mingw to port wine > > > Date: Tue, 28 May 2002 17:21:31 -0400 > > > > > > Steven Edwards wrote: > > > > > > > > I just copyed the /share/bison.simple and bison.hairy to /bin and it > > > > worked fine. Like I said nothing major. > > > > > > That's strange. Oh, probably not that strange, it has to do with > > > /mingw/share/... not being resolved within bison. I'll have to take a > > > look at the source for this. The other solution could have been > > > export BISON_SIMPLE=D:/mingw/share/bison.simple > > > export BISON_HAIRY=D:/mingw/share/bison.hairy > > > > Has the "/mingw/share/... not being resolved within bison" > > situation changed? > > > > I have: MSYS-1.0.8-i686-2002.06.25-1.exe > > latest snapshot is: MSYS-1.0.8-2002.09.07-1.exe > > > > Steven's fix works for me. I know I could set environment > > variables too. But I'm trying to write up procedures for > > others to use, and if this just works effortlessly in a > > later release with neither of those workarounds, then > > it's one less thing to document. > > The gnuwin32 port of bison has been patched to look for data files relative > to the bin directory, so using the binary distribution of that package is > probably the simplest solution. Doesn't the mingwDTK bison already look for data files in the bin directory, since, as Steven says, if you copy the files there it just works? Is there any plan to change mingwDTK bison so that either it looks in the directory where it puts the files, or puts the files in the directory it looks in? I don't have anything against gnuwin32 or any other project, but I just prefer to use stuff from the mingw maintainers. Maybe it's a silly prejudice, and I wouldn't push it on anyone else, but I earn my living with these tools, I need to know and trust the people that maintain them, and I can only subscribe to so many mailing lists. |
From: Earnie B. <ear...@ya...> - 2002-11-14 12:13:37
|
Greg Chicares wrote: > > Doesn't the mingwDTK bison already look for data files > in the bin directory, since, as Steven says, if you > copy the files there it just works? > I haven't tried it yet. > Is there any plan to change mingwDTK bison so that > either it looks in the directory where it puts the > files, or puts the files in the directory it looks in? > I've added it to my round tuit list. If you could provide a simple test package for regression testing in would help. I'll see if a rebuild with the current rc-2+ will help. The bison configuration needs adjusted for an absolute win32 path. > I don't have anything against gnuwin32 or any other > project, but I just prefer to use stuff from the > mingw maintainers. Maybe it's a silly prejudice, > and I wouldn't push it on anyone else, but I earn > my living with these tools, I need to know and > trust the people that maintain them, and I can > only subscribe to so many mailing lists. > I understand your point and agree. Earnie. |
From: Greg C. <chi...@mi...> - 2002-11-15 06:08:34
|
Earnie Boyd wrote: > > Greg Chicares wrote: > > > > Is there any plan to change mingwDTK bison so that > > either it looks in the directory where it puts the > > files, or puts the files in the directory it looks in? > > I've added it to my round tuit list. If you could provide a simple test > package for regression testing in would help. I'll see if a rebuild > with the current rc-2+ will help. The bison configuration needs > adjusted for an absolute win32 path. I think years ago Mumit routinely built wxWindows as part of his validation suite before releasing a mingw version. Building that package with MSYS ./configure ; make will test bison. If that's not part of your routine validation, then let me know and I'll provide a much simpler test package--wxWindows it too big if you're not using it already. |
From: Earnie B. <ear...@ya...> - 2002-11-15 12:13:20
|
Greg Chicares wrote: > Earnie Boyd wrote: > >>Greg Chicares wrote: >> >>>Is there any plan to change mingwDTK bison so that >>>either it looks in the directory where it puts the >>>files, or puts the files in the directory it looks in? >> >>I've added it to my round tuit list. If you could provide a simple test >>package for regression testing in would help. I'll see if a rebuild >>with the current rc-2+ will help. The bison configuration needs >>adjusted for an absolute win32 path. > > > I think years ago Mumit routinely built wxWindows > as part of his validation suite before releasing > a mingw version. Building that package with MSYS > ./configure ; make > will test bison. > > If that's not part of your routine validation, > then let me know and I'll provide a much simpler > test package--wxWindows it too big if you're not > using it already. > No, I'm not using it already. Yes, it's too big just for this regression test. Earnie. |
From: Greg C. <chi...@mi...> - 2002-11-24 23:03:42
Attachments:
bison-test-case.tar.bz2
|
Earnie Boyd wrote on 2002-11-14T07:13:31-0500: > > Greg Chicares wrote: > > > > Is there any plan to change mingwDTK bison so that > > either it looks in the directory where it puts the > > files, or puts the files in the directory it looks in? > > I've added it to my round tuit list. If you could provide a simple test > package for regression testing in would help. I'll see if a rebuild > with the current rc-2+ will help. The bison configuration needs > adjusted for an absolute win32 path. Attached is a simple test case. It's the example from the bison manual, cleaned up slightly to prevent warning and error messages. The enclosed readme should give a complete description. One thing I'll note here too, though, because it may be of general interest: bison.hairy has been removed by the maintainers. Thus, setting a BISON_HAIRY variable in the environment no longer has any effect. Details here: http://savannah.gnu.org/cgi-bin/cvsweb/bison/NEWS Revision 1.39 ... Thu May 2 15:06:46 2002 UTC | Remove the so called hairy (semantic) parsers. ... | * data/bison.hairy: Remove. | * doc/bison.texinfo (Environment Variables): Remove occurrences of | BISON_HAIRY. Users may wish to remove BISON_HAIRY from any makefiles that define it, since the directive that triggers its use has been broken 'for ages': http://mail.gnu.org/pipermail/bison-patches/2002-May/000851.html | +* Semantic parser | + This old option, which has been broken for ages, is removed. |
From: Dave M. <win...@nt...> - 2002-11-14 07:18:09
|
hi does anyone know if there is a MinGW port of glibc? If not how would I go about providing one? it appears that I need to have perl installed to compile the latest binutils for my cross compiler endeavours. Is there a binary available for that? Dave |
From: Paul G. <pga...@at...> - 2002-11-14 23:18:38
|
Afaik, there is not an executable with the name glibc.exe currently available with the Mingw distro/install. > hi > > does anyone know if there is a MinGW port of glibc? If not how would I > go about providing one? (following assumes you are building for Mingw, not for Msys) a) do a search (recommend google.com) for glibc (It is Gnu Software) b) download the latest, and this is important, "stable" version of glibc. c) Read through all the necessary documentation associated with glibc that comes with the download. d) check web for other documentation re: glibc from other platforms (apart from your native platform which could be whatever). e) find a mailing list that is dedicated to glibc and is maintained by other developers of glibc. f) subscribe to that mailing list for the very best technical support for glibc. g) Try and build glibc. h) track down any bugs or compiler errors that might come up and deal with them as you see fit. i) repeat g-h until you have a working, Mingw based, executable that will run on your native platform (be it Unix, Linux, or whatever). Question 2: > > it appears that I need to have perl installed to compile the latest > binutils for my cross compiler endeavours. Is there a binary available > for that? Mmm...not sure which platform you are building for. Binutils typically do not need, nor are they dependent on any perl references/perl functionality*. If you have to (read as "must" or "are required to") deal with perl references then I suggest you use Msys environment for your glibc port. *perl (.php?) functionality is useful only if you are or need to be building or using perl scripts. Paul G. |
From: Dave M. <win...@nt...> - 2002-11-17 08:45:43
|
aha, that's what happened this message :) Replied direct instead of to list I noticed some mails on the list that suggest a glibc port is already in progress but I'd be interested in learning the procedure for that anyway. >Afaik, there is not an executable with the name glibc.exe >currently available with the Mingw >distro/install. sorry, I should have been clearer. The package in question is glibc as found here http://www.gnu.org/software/libc/ tm, I'm trying to produce a mingw based cross compiler for ARM target ("arm-mingw-elf", "arm-pc-mingw"?) Currently I've got as far as compiling an old version of binutils (2.11.2) so I thought I'd see what happened with the binutils supplied with mingw. I nabbed the source for 2.13.90 here http://sourceforge.net/projects/mingw/ unfortunately I get a lot of perl related errors due to not having perl on my mingw/minsys setup. This appears to be part of the compile process. On a totally unrelated tack, I've been playing with protracker source in an attempt to find a PC module player which actually complies with the original protracker spec. None I've found so far can actually play most of my module collection as intended due to various assumptions relating to timing :( I found linux source for protracker at http://www.ibiblio.org/pub/Linux/apps/sound/players/ (tracker-4.3-linux.tar.gz) this requires sys/soundcard.h which can apparently be found in glibc-devel according to someone in #linuxhelp on efnet. having got the source for glibc & attempted to configure I get a message saying that I can't configure for i686-pc-mingw, talk to someone about a port. This is kind of fun so I thought I'd see how I could do this & share my efforts. I've looked here for glibc & perl http://sourceforge.net/projects/mingwrep/ any pointers on learning about setting up this port? I've mailed Ulrich Drepper listed as responsible for sysdeps/i386 but haven't had a reply as yet. the docs have this to say "To port glibc to a new platform means basically to: Read the documentation and understand the structure of the sysdeps directory. configure glibc with --enable-hacker-mode running make and filling in the sysdeps directory. You should not need to touch any files outside the sysdeps directory besides some configure stuff." To get the port integrated into the official glibc release, you have to file copyright papers to the FSF (for details ask the maintainers)." I'm assuming that all I really need is to understand the sysdeps stuff & sort it out so it recognises my host system. Or is that being a little optimistic? Any hints & tips on finding the relevant documentation would be greatly appreciated. Dave |
From: Luke D. <cod...@ho...> - 2002-11-17 09:29:15
|
----- Original Message ----- From: "Dave Murphy" <win...@nt...> To: <min...@li...> Sent: Sunday, November 17, 2002 4:44 PM Subject: RE: [Mingw-users] porting > aha, that's what happened this message :) Replied direct instead of to list > > I noticed some mails on the list that suggest a glibc port is already in > progress but I'd be interested in learning the procedure for that anyway. > > > >Afaik, there is not an executable with the name glibc.exe > >currently available with the Mingw > >distro/install. > > sorry, I should have been clearer. The package in question is glibc as found > here > > http://www.gnu.org/software/libc/ > > tm, I'm trying to produce a mingw based cross compiler for ARM target > ("arm-mingw-elf", "arm-pc-mingw"?) Currently I've got as far as compiling an > old version of binutils (2.11.2) so I thought I'd see what happened with the > binutils supplied with mingw. The host of your compiler would be "mingw32" or "i386-pc-mingw32", and the target would probably be "arm-unknown-elf". Unless your target system is running Win32 the target string should not contain "mingw". > > I nabbed the source for 2.13.90 here > > http://sourceforge.net/projects/mingw/ > > unfortunately I get a lot of perl related errors due to not having perl on > my mingw/minsys setup. This appears to be part of the compile process. You could try using perl from the msysDTK package, but I'm not sure what it would be used for when building binutils. Can you give an example of what perl scripts are involved in binutils? > > On a totally unrelated tack, I've been playing with protracker source in an > attempt to find a PC module player which actually complies with the original > protracker spec. None I've found so far can actually play most of my module > collection as intended due to various assumptions relating to timing :( I > found linux source for protracker at > http://www.ibiblio.org/pub/Linux/apps/sound/players/ > (tracker-4.3-linux.tar.gz) > > this requires sys/soundcard.h which can apparently be found in glibc-devel > according to someone in #linuxhelp on efnet. [snip] > > I'm assuming that all I really need is to understand the sysdeps stuff & > sort it out so it recognises my host system. Or is that being a little > optimistic? > So the reason you want to port glibc to Mingw is to compile "tracker" for Windows? I'm afraid there is practically zero chance of being able to port glibc to Win32 because it requires a POSIX or Unix-like operating system. I expect that the soundcard support is specific to Unix too, so the only realistic option would be to modify "tracker" to use Windows audio APIs, but you should expect this to be _difficult_. There might be libraries available that make porting audio applications from Linux to Win32 easier, but I don't know. > Any hints & tips on finding the relevant documentation would be greatly > appreciated. > > > Dave Luke Dunstan |
From: Dave M. <win...@nt...> - 2002-11-17 14:48:08
|
>The host of your compiler would be "mingw32" or >"i386-pc-mingw32", and the >target would probably be "arm-unknown-elf". Unless your target >system is >running Win32 the target string should not contain "mingw". fair enough. I wanted to avoid 'unknown' as it seems a bit negative and, given that the resulting compiler will generate code for any ARM based platform, it seems a little silly to use a specific platform name. >You could try using perl from the msysDTK package, but I'm not >sure what it >would be used for when building binutils. Can you give an >example of what >perl scripts are involved in binutils? closer inspection reveals the perl stuff to be nothing majorly serious. It's generating the documentation. Making all in doc make[3]: Entering directory `/c/projects/mingw/arm-elf-binutils/binutils/doc' touch addr2line.1 perl ../../../binutils-2.13.90/binutils/../etc/texi2pod.pl -Dman -Daddr2line < ../../../binutils-2.13.90/binutils/doc/binutils.texi > addr2line.pod (pod2man --center="GNU Development Tools" --release="binutils-2.13.90" --section=1 addr2line.pod | sed -e '/^.if n .na/d' > addr2line.1.T$$ && \ mv -f addr2line.1.T$$ addr2line.1) || (rm -f addr2line.1.T$$ && exit 1) rm -f addr2line.pod touch ar.1 this reports perl & pod2man not found but continues anyway I'm haveing trouble with bison though :- /bin/sh ../../binutils-2.13.90/binutils/../ylwrap "bison -y" ../../binutils-2.13.90/binutils/arparse.y y.tab.c arparse.c y.tab.h arparse.h -- -d c:\mingw\bin\bison.exe cannot open file c:\mingw\bin\bison.simple No such file or directory make[3]: [arparse.c] Error 1 Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' make[2]: [all-recursive] Error 1 Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' make[1]: [all-recursive-am] Error 2 Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' what is bison.simple? Do I need to set something else up? > >So the reason you want to port glibc to Mingw is to compile >"tracker" for Windows? I didn't say it was sensible :) >you should expect this to be _difficult_. There might be >libraries available >that make porting audio applications from Linux to Win32 >easier, but I don't know. I'm actually mainly interested in getting to a low level with the PC sound hardware anyway. I still have trouble with the concept of a 16MHz 68030 based machine with cheap audio hardware outperforming a Soundblaster equipped PIII450 for some things. Dave |
From: Luke D. <cod...@ho...> - 2002-11-18 01:14:09
|
----- Original Message ----- From: "Dave Murphy" <win...@nt...> To: "'Luke Dunstan'" <cod...@ho...>; <min...@li...> Sent: Sunday, November 17, 2002 10:31 PM Subject: RE: [Mingw-users] porting [snip] > > I'm haveing trouble with bison though :- > > /bin/sh ../../binutils-2.13.90/binutils/../ylwrap "bison -y" > ../../binutils-2.13.90/binutils/arparse.y y.tab.c arparse.c y.tab.h > arparse.h -- -d > > c:\mingw\bin\bison.exe cannot open file c:\mingw\bin\bison.simple No such > file or directory > > make[3]: [arparse.c] Error 1 > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > make[2]: [all-recursive] Error 1 > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > make[1]: [all-recursive-am] Error 2 > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > > > what is bison.simple? Do I need to set something else up? If you got bison from mingwDTK you should have files bison.simple and bison.hairy in /mingw/share/bison, so you can either define these environment variables: export BISON_SIMPLE=c:/mingw/share/bison/bison.simple export BISON_HAIRY=c:/mingw/share/bison/bison.hairy (e.g. in your ~/.profile) or you can move the data files into your Mingw bin directory. > > >you should expect this to be _difficult_. There might be > >libraries available > >that make porting audio applications from Linux to Win32 > >easier, but I don't know. > > I'm actually mainly interested in getting to a low level with the PC sound > hardware anyway. I still have trouble with the concept of a 16MHz 68030 > based machine with cheap audio hardware outperforming a Soundblaster > equipped PIII450 for some things. > > > Dave > Luke |
From: Paul G. <pga...@at...> - 2002-11-19 00:26:12
|
> > I'm haveing trouble with bison though :- > > /bin/sh ../../binutils-2.13.90/binutils/../ylwrap "bison -y" > ../../binutils-2.13.90/binutils/arparse.y y.tab.c arparse.c y.tab.h > arparse.h -- -d > > c:\mingw\bin\bison.exe cannot open file c:\mingw\bin\bison.simple No > such file or directory > > make[3]: [arparse.c] Error 1 > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > make[2]: [all-recursive] Error 1 > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > make[1]: [all-recursive-am] Error 2 > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > > > what is bison.simple? Do I need to set something else up? bison.simple, from one standpoint, is just the original Unix reference for the Windows Platform (Win32) bison. Afaik, bison == bison.simple. The only difference is that the Windows platform versions of bison don't usually tend to add the extra ".simple" as there is only one "bison" that is typically used (ie. "bison"). It is like the old saying, "You say 'tomahtoes', I say, 'Tomatoes'..", afaik it is a name thing only. > I'm actually mainly interested in getting to a low level with the PC > sound hardware anyway. > I still have trouble with the concept of a > 16MHz 68030 based machine with cheap audio hardware outperforming a > Soundblaster equipped PIII450 for some things. (pardon me while I wax nostalgic) *heh*, best get used to it. The 68x family of processors has always outperformed and outprocessed the Ix86 family of processors and continues (Motorola cpus) to do so. In fact, the MC68x (16Mhz) was running operating systems as complex as Macs OSX long before Ix86, or even Intel, actually had much of an existence. (semi-ot: History buffs, if you are interested, you can do a search on the Amiga OS. It was, and those Amigas which are still being used are still based on the Motorola processor family/architecture. Afaik, there are still quite a few Amiga User Groups active and functioning, even today). Fwiw, if I could I would rather be running an MC68x, 16Mhz on this platform (currently using Windows based OS for replies to email) then I would anything else short of a Sparc based platform. MC68x is an old friend and I miss it a lot. Paul G. |
From: Earnie B. <ear...@ya...> - 2002-11-19 01:51:27
|
Paul G. wrote: > > bison.simple, from one standpoint, is just the original Unix reference for the > Windows Platform (Win32) bison. Afaik, bison == bison.simple. The only difference is that > the Windows platform versions of bison don't usually tend to add the extra ".simple" as there > is only one "bison" that is typically used (ie. "bison"). > > It is like the old saying, "You say 'tomahtoes', I say, 'Tomatoes'..", afaik it is a name > thing only. > Are you speaking from experience or just blowing smoke? The bison.simple and bison.hairy aren't the executable bison. They are template files for bison. So, the tomatoes are on your face. ;) Earnie. |
From: Luke D. <cod...@ho...> - 2002-11-19 01:52:10
|
----- Original Message ----- From: "Paul G." <pga...@at...> To: <min...@li...> Sent: Tuesday, November 19, 2002 8:26 AM Subject: RE: [Mingw-users] porting > > > > > > I'm haveing trouble with bison though :- > > > > /bin/sh ../../binutils-2.13.90/binutils/../ylwrap "bison -y" > > ../../binutils-2.13.90/binutils/arparse.y y.tab.c arparse.c y.tab.h > > arparse.h -- -d > > > > c:\mingw\bin\bison.exe cannot open file c:\mingw\bin\bison.simple No > > such file or directory > > > > make[3]: [arparse.c] Error 1 > > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > > make[2]: [all-recursive] Error 1 > > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > > make[1]: [all-recursive-am] Error 2 > > Leaving directory `/c/projects/mingw/arm-elf-binutils/binutils' > > > > > > what is bison.simple? Do I need to set something else up? > > bison.simple, from one standpoint, is just the original Unix reference for the > Windows Platform (Win32) bison. Afaik, bison == bison.simple. The only difference is that > the Windows platform versions of bison don't usually tend to add the extra ".simple" as there > is only one "bison" that is typically used (ie. "bison"). > > It is like the old saying, "You say 'tomahtoes', I say, 'Tomatoes'..", afaik it is a name > thing only. [snip] > > Paul G. Paul, bison.simple and bison.hairy are data files used by bison and typically stored in $prefix/share/bison. Luke |
From: Earnie B. <ear...@ya...> - 2002-11-17 13:08:57
|
Dave Murphy wrote: > aha, that's what happened this message :) Replied direct instead of to list > > I noticed some mails on the list that suggest a glibc port is already in > progress but I'd be interested in learning the procedure for that anyway. > > > >>Afaik, there is not an executable with the name glibc.exe >>currently available with the Mingw >>distro/install. > > > sorry, I should have been clearer. The package in question is glibc as found > here > > http://www.gnu.org/software/libc/ > > tm, I'm trying to produce a mingw based cross compiler for ARM target > ("arm-mingw-elf", "arm-pc-mingw"?) Currently I've got as far as compiling an > old version of binutils (2.11.2) so I thought I'd see what happened with the > binutils supplied with mingw. > So what you really need is newlib (see: http://sources.redhat.com). They support arm using gcc. Earnie. |
From: Dave M. <win...@nt...> - 2002-11-20 00:46:37
|
> tm, I'm trying to produce a mingw based cross compiler for ARM target >> ("arm-mingw-elf", "arm-pc-mingw"?) Currently I've got as far >as compiling an >> old version of binutils (2.11.2) so I thought I'd see what >happened with the >> binutils supplied with mingw. >> > >So what you really need is newlib (see: http://sources.redhat.com). >They support arm using gcc. > >Earnie. nope, the glibc stuff was related to playing around with tracker code that needed "sys/soundcard.h" which is apparently part of glibc. This was unrelated to the ARM stuff. In any case I fail to see why a standard library of any description would support any particular processor. Dave |