This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: makeflags, cross-compiling, and col


On 1 Jun 2001, at 19:12, Suhaib Siddiqi wrote:

> I have never compiled Xfree86 with a cross-compiler under Cygwin.
> Therefore I do not guarantee my suggestions will work.  I am certain you
> Will need to do a lot of hacking.
> 

Thanks for the help.  I've come that that same conclusion.

> > 
> > How can I get rid of the --unix in Makeflags?  I'm trying to do make
> > World and nested down in a bunch of the subdirectories, when
> > make gets to this section of the Makefile,
> > 
> > $(ONESUBDIR)/Makefile:
> >         @for flag in ${MAKEFLAGS} ''; do \
> >         case "$$flag" in *=*) ;; *[n]*) executeit="no";; esac; done; \
> >         cd $(ONESUBDIR) && \
> >         if [ "$$executeit" != "no" ]; then \
> >         $(IMAKEPREFIX)$(IMAKE) -I$(IMAKEPREFIX)$(IRULESRC)
> > $(IMAKE_DEFINES) -DTO
> > PDIR=$(IMAKETOP) -DCURDIR=$(ONECURDIR)$(ONESUBDIR); \
> >         fi;
> 
> 
> this rule is in xc/config/xc/Imake.rules.  
> 
> @MakeFlagsToShellFlags(n,executeit="no"); \                     @@\
>  cd $(ONESUBDIR) && \                                            @@\
>  if [ "$$executeit" != "no" ]; then \                            @@\
> 
> If you fix the Imake.rules file, your Makefiles should be generated without
> --unix makeflags?
> 
> > 
> > it basically sees the --unix in MAKEFLAGS, sets executeit="no" and
> > then doesn't run Imake to create the Makefile in each of the
> > subdirectories.  I don't know enough about makefiles yet to know
> > why, so here is one of my questions.
> > 
> > What is the real intention of that?  Just ignoring that case statement
> > lets the Makefiles get built, which is obviously the ultimate intention
> > since if they didn't need to be built, doing a make World wouldn't
> > choke with the statement that it couldn't find a rule to make clean in
> > that subdir.
> 
> I do not know what is the real intention of that.  Perhaps Alan can shed
> Light on it?
> 

Hmmm.  Well, I see how I can hack that Imake.rules file to always 
ignore that --unix makeflag (or all makeflags), but I don't see how I 
can get --unix 'out' of the makeflag so the Imake.rules file won't have 
that problem.  I'm just a little leary about hacking functionality out of 
the process without understanding why someone else put it in (and 
what the implications of hacking it out really are).


> 
> > 
> > I'm trying to build under cygwin, but I'm using a gcc cross-compiler
> > targeting linux.
> > 
> > My other problem (well, one of them) is that I was having a hard time
> > convincing the Imake process to actually use the cross-compiler.
> > I've seen the few examples, but I ended up just setting my cross-
> > compiler as the default compiler and the few things that needed to
> > be compiled native (like imake, makekeys, makestrs) I compiled
> > separately and removed the compile references from the make
> > process.  This seems to have worked, but it seems less clean than
> > running a real multi-compiler environment and I'm not sure it is an
> > adequate solution.  It also still throws up a number of dialog box
> > errors in certain spots similar to what I get when I try to execute a
> > linux program on my win2k machine from within bash.  I haven't
> > figured out where it is yet, but it's right after it does a ranlib on some
> > lib and then an rf -f on that same lib. Would I be better off using a
> > true multi-cross-compiler environment?  And if so, how?  When I
> > was doing it, it always pulled in the cygwin.cf file and what I really
> > need is for it to pull in the linux.cf file (which it does in my hacked
> > version)?
> 
> 
> Under Cygwin it supposed to pickup cygwin.cf. I am not a cross-compiler
> expert therefore I do not know what to tell you about ranlib etc errors.
> 
Yeah, unfortunately I'm not either.  I am able to get through to the 
end by just pushing on through the dialog boxes, so although 
extremely annoying, it's not a complete showstopper at this point.  It 
would be nice to have it flow smoothly though.  Anybody else out 
there have any thoughts?

> > 
> > Lastly, it was also choking because it couldn't find the col utility
> > which I don't find in cygwin but I do find in linux.  I managed to use
> > a pair of jumper cables and arc around that issue, but I'd like to
> > know what the proper way of handling this is.  Get the sources for
> > col and recompile under native cygwin? (where?)  Patch in cat in
> > place of col which is what it looks like is done for os2?
> 
> You will need to port col utility.  I am sure sources should be on Linux
> SRMS CD.  Extract the SRPM file on a linux machine with rpm2cpio.  It 
> Should give you a *.tar.gz file, move it to your machine where Cygwin is
> intsall, and port it to Cygwin.  You may ask Cygwin mailing list
> cygwin@cygwin.com if someone has arleady ported it to Cygwin.
> 
> 
> Suhaib
> 

Thanks for the help.
-Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]