[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) a
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] working version of gnuradio for windows (mingw) available including audio-sink and wxgui |
Date: |
Wed, 13 Jul 2005 18:05:00 -0700 |
User-agent: |
Mutt/1.5.6i |
On Thu, Jul 14, 2005 at 01:23:46AM +0200, Stephane Fillod wrote:
> On Wed, Jun 29, 2005 at 05:38:28AM -0700, Eric Blossom wrote:
> > In the bigger picture, we need to revisit the strategy for
> > searching for libpython. This is currently breaking the build on
> > x86-64 and OS/X. My biggest complaint is that we have introduced a
> > mostly-unneeded dependency that has made our build environment
> > brittle.
> >
> > Stephane, what I like to see is that the check for libpython and the
> > corresponding -no-undefined flag only happen on platforms that are
> > building windows DLLs.
>
> This work is under way. We still need to fix libpython linking under
> MinGW before 2.6. This shouldn't be a big issue, Martin may have
> it already working.
Good.
> > Is there another way to make this work? OS/X is case preserving but
> > case-insensitive.
>
> How does gcc work if there's no difference between upper and lower
> case?
It preserves case so that if you read the directory, you can tell a .S
from a .s
However, an open of "foo.s" will open a "foo.S". There can't be both
a foo.s and a foo.S in the same directory. They'd refer to the same
file.
> As stated in the manual, an upper case extension .S will call
> the preprocessor while the lower case extension .s doesn't.
> Can some under OS/X make a quick test?
>
> >I think OS/X users will be screwed by this
> > change -- basically they won't see it.
>
> Do you mean the preprocessor won't be called, or the dependency system
> won't rebuild the objects? If it's the latter case, then a "make clean"
> can get away with it.
> BTW, the Windows platform suffers the same "issue" with case-sensitiveness
> as OS/X do.
I think I may have misunderstood your original proposal. Is it to
replace the .s's with .S's so that you can run the preprocessor on
them? If so, then I concur that the question below is the key:
> If someone know how to turn on the preprocessor for the assembly files
> under Windows and OS/X, please stand up :-)
Eric