RE: Using the new cross compilation system - and a request for help
On Thu, 11 Jul 2002, Harold Hunt wrote: Excellent. I have applied just such a fix. Thank you for tracking this down. Now, regarding the imakemdep_cpp.h that I sent you, have you seen warnings similar to the ones I'm getting below? The reason I asked if your imakemdep_cpp.h was similar was because I wanted to know if it has those ``#1 imakedep_cpp.h'' lines like mine does. no. This is line information added by the preprocessor. I don't know why my preprocessor did not add them :) I'll take a closer look when I'm home again. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
On Tue, 9 Jul 2002, Harold L Hunt wrote: 1) We are building gen_matypes.c and we are supposed to create an executable that will be used during the compilation process to build a header file called ``matypes.h''. However, this executable is being built with ``cc'' (it isn't clear if this is the link to /cygwin/bin/cc or if it is the host cc) but we are calling it ``gen_matypes.exe'', which is clearly wrong because we want an executable to use while cross compiling, not an installable executable. diff -U3 -r1.22 Imakefile --- lib/GL/mesa/src/X86/Imakefile 2002/03/01 21:21:48 1.22 +++ lib/GL/mesa/src/X86/Imakefile 2002/07/11 15:24:06 @@ -85,11 +85,11 @@ MATYPES = ./gen_matypes matypes.h: gen_matypes.c - RemoveFiles($@ ProgramTargetName(gen_matypes)) - -HostLinkRule(ProgramTargetName(gen_matypes),$(CFLAGS) $(LOCAL_LDFLAGS),gen_matypes.c,$(LDLIBS)) + RemoveFiles($@ HostProgramTargetName(gen_matypes)) + -HostLinkRule(HostProgramTargetName(gen_matypes),$(CFLAGS) +$(LOCAL_LDFLAGS),gen_matypes.c,$(LDLIBS)) RunProgram(MATYPES, matypes_h) $(MV) matypes_h $@ - RemoveFiles(ProgramTargetName(gen_matypes)) + RemoveFiles(HostProgramTargetName(gen_matypes)) includes:: matypes.h 2) Building gen_matypes.c fails because it cannot find glheader.h, mypes.h, and tnl/t_context.h, which are stored over in xc/extras/Mesa/src, but it appears that they should be copied during the build process to build/std/exports/include. For some reason, they are not being copied there. no problem for me. Maybe they are not created because gen_matypes failes before There is a new problem that needs a better answer than the one that I've got right now. In xc/config/imake/imakedep.h there is a define that turns an empty define for i686 into i686 == 1. For some reason, i686 is now defined during a cross compilation build and it causes our executable names, such as ``i686-pc-cygwin-gcc'' and our include directories (``i686-pc.. you get the point...) to become ``1-pc-cygwin-gcc''. I had to add a ``#undef i686'' to the new host.def that is used when cross compiling. you don't need the i686-pc-cygwin32-gcc program names anymore. For me, a call to cross-gcc is /usr/i686-pc-cygwin32/bin/`echo gcc|sed s%.*/%%` I'll see if the imake patch compiles and will send a patch later. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
Alexander Gottwald [EMAIL PROTECTED] said: On Tue, 9 Jul 2002, Harold L Hunt wrote: 1) We are building gen_matypes.c and we are supposed to create an executable that will be used during the compilation process to build a header file called ``matypes.h''. However, this executable is being built with ``cc'' (it isn't clear if this is the link to /cygwin/bin/cc or if it is the host cc) but we are calling it ``gen_matypes.exe'', which is clearly wrong because we want an executable to use while cross compiling, not an installable executable. diff -U3 -r1.22 Imakefile --- lib/GL/mesa/src/X86/Imakefile 2002/03/01 21:21:48 1.22 +++ lib/GL/mesa/src/X86/Imakefile 2002/07/11 15:24:06 @@ -85,11 +85,11 @@ MATYPES = ./gen_matypes matypes.h: gen_matypes.c - RemoveFiles($@ ProgramTargetName(gen_matypes)) - -HostLinkRule(ProgramTargetName(gen_matypes),$(CFLAGS) $(LOCAL_LDFLAGS),gen_matypes.c,$(LDLIBS)) + RemoveFiles($@ HostProgramTargetName(gen_matypes)) + -HostLinkRule(HostProgramTargetName(gen_matypes),$(CFLAGS) $(LOCAL_LDFLAGS),gen_matypes.c,$(LDLIBS)) RunProgram(MATYPES, matypes_h) $(MV) matypes_h $@ - RemoveFiles(ProgramTargetName(gen_matypes)) + RemoveFiles(HostProgramTargetName(gen_matypes)) includes:: matypes.h I have already made such a patch to my local tree. It works fine. I thought I made a post a day or two ago with a patch for cross compiling? I thought it had just such a patch in it? Am I losing my mind? 2) Building gen_matypes.c fails because it cannot find glheader.h, mypes.h, and tnl/t_context.h, which are stored over in xc/extras/Mesa/src, but it appears that they should be copied during the build process to build/std/exports/include. For some reason, they are not being copied there. no problem for me. Maybe they are not created because gen_matypes failes before Nope. gen_matypes needs those headers before it is build, since gen_matypes.c includes those headers. What is happening here is that the HostLinkRule (which you created, I believe) over in xc/config/cf/cross.rules does nothing with the flags parameter. I recall that we couldn't pass the flags parameter because it was defining some things that ought not to be defined when cross compiling. However, I have modified my HostLinkRule to pass the flags on just as LinkRule does and I have built the whole tree without problems. I think only one other executable uses HostLinkRule, so as long as these two things build we are in the clear. Have you modified your locak HostLinkRule, or is cross.rules not being processed on your system? Oh yeah, the flags, in this case, contain -I../../../../exports/include (or something close to that, I don't feel like looking it up for an exact quote), which points the compiler to glheader.h, mtypes.h, and tnl/t_context.h. There is a new problem that needs a better answer than the one that I've got right now. In xc/config/imake/imakedep.h there is a define that turns an empty define for i686 into i686 == 1. For some reason, i686 is now defined during a cross compilation build and it causes our executable names, such as ``i686-pc-cygwin-gcc'' and our include directories (``i686-pc.. you get the point...) to become ``1-pc-cygwin-gcc''. I had to add a ``#undef i686'' to the new host.def that is used when cross compiling. you don't need the i686-pc-cygwin32-gcc program names anymore. For me, a call to cross-gcc is /usr/i686-pc-cygwin32/bin/`echo gcc|sed s%.*/%%` How do I make it through life without accidentally killing myself? I must have tried 20 ways of defining the cross compiler names, or not defining them, etc., and I never got a build to work until I started setting them to i686-pc-cygwin-gcc and so forth. Then you mention that they don't need to have i686-pc-cygwin in them anymore, I try it, and voila, like magic it works. What gives? Can't I get a break anymore? Oh yeah, and you are correct. We don't need the i686-pc-cygwin prefix anymore. I'll see if the imake patch compiles and will send a patch later. What imake patch? I have had problems with imake not compiling because imake.c is looking for glibc_major and glibc_minor, which are supposed to be defined in imakemdep.h, but for whatever reason the #if's are wrong and imakemdep.h doesn't define them but imake.c still ends up expecting them. Please figure this one out for me, it is really bugging me. For now I've just changed imake.c and substituted 0's for glibc_major and glibc_minor. Harold bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? Harold depending in programs/lbxproxy/os... make[4]: Entering directory `/home/harold/x-devel/build/newhostdef/programs/lbxproxy/os' ./../../config/makedepend/makedepend -- -I../include -I../../../include -I../../../include/extensions-I../../../include/extensions -I../../.. -I../../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_ALLOCA -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DPIXPRIV -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree86Server -DXF86VIDMODE -DXvMCExtension-DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DTCPCONN -DUNIXCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXvExtension -DXFree86Server -DXF86VIDMODE -DXvMCExtension-DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DDDXTIME -DFD_SETSIZE=256 -DDDXOSINIT -DDDXOSVERRORF -DDDXOSFATALERROR -I../../../lib/xtrans -DUSE_MAKEDEPEND -- connection.c io.c WaitFor.c osinit.c transport.c ./../../config/makedepend/makedepend: warning: connection.c (reading ./../../include/Xos.h, line 59): cannot find include file sys/types.h not in ../include/sys/types.h not in ../../../include/sys/types.h not in ../../../include/extensions/sys/types.h not in ../../../include/extensions/sys/types.h not in ../../../sys/types.h not in ../../../exports/include/sys/types.h not in ../../../lib/xtrans/sys/types.h not in /sys/types.h not in /cygwin/1-pc-cygwin/include/sys/types.h not in /cygwin/1-pc-cygwin/include/w32api/sys/types.h not in /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include/sys/types.h
Re: Using the new cross compilation system - and a request for help
On Thu, 11 Jul 2002, Harold L Hunt wrote: Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? That define is only used, if i686 is already used. For me imakemdep_cpp.h is generated this way /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; with ./ccimake just echoing -DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin -DCROSSCOMPILE -O can you please check, from where the i686 define gets into the imakemdep generation? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
On Thu, 11 Jul 2002, Harold L Hunt wrote: I have already made such a patch to my local tree. It works fine. I thought I made a post a day or two ago with a patch for cross compiling? I thought it had just such a patch in it? Am I losing my mind? Hm, such a patch never reached me. Just a posting with the modified cross- compiling guide bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
--- Alexander Gottwald [EMAIL PROTECTED] wrote: On Thu, 11 Jul 2002, Harold L Hunt wrote: Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? That define is only used, if i686 is already used. For me imakemdep_cpp.h is generated this way /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; with ./ccimake just echoing -DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin -DCROSSCOMPILE -O ^^ Why is this naming convention being used? That is a relic of B20, we shouldn't use that anymore. Damn those bloody SuSE people for ruining our cross compile system! Cheers, Nicholas __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
Re: Using the new cross compilation system - and a request for help
Alexander Gottwald [EMAIL PROTECTED] said: On Thu, 11 Jul 2002, Harold L Hunt wrote: I have already made such a patch to my local tree. It works fine. I thought I made a post a day or two ago with a patch for cross compiling? I thought it had just such a patch in it? Am I losing my mind? Hm, such a patch never reached me. Just a posting with the modified cross- compiling guide bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 You are right. I never posted my patch. I got sidetracked. Oh well, Harold
Re: Using the new cross compilation system - and a request for help
Alexander Gottwald [EMAIL PROTECTED] said: On Thu, 11 Jul 2002, Harold L Hunt wrote: Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? That define is only used, if i686 is already used. For me imakemdep_cpp.h is generated this way /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; with ./ccimake just echoing -DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin -DCROSSCOMPILE -O can you please check, from where the i686 define gets into the imakemdep generation? I don't get it. What build command are you using? I am using: make CROSSCOMPILEDIR=/cygwin/bin World World.log 21 Are you talking about imakemdep_cpp.h being built during the World make, or are you doing this during a seperate step? Harold bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
Nicholas Wourms [EMAIL PROTECTED] said: --- Alexander Gottwald [EMAIL PROTECTED] wrote: On Thu, 11 Jul 2002, Harold L Hunt wrote: Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? That define is only used, if i686 is already used. For me imakemdep_cpp.h is generated this way /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; with ./ccimake just echoing -DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin -DCROSSCOMPILE -O ^^ Why is this naming convention being used? That is a relic of B20, we shouldn't use that anymore. Damn those bloody SuSE people for ruining our cross compile system! Cheers, Nicholas Hey now, go easy on the Suse folks. The end result of their changes will be a much more solid and complete cross compilation system for Cygwin. Most of the problems that we are running into are just due to me not keeping a cross compile tree that I rebuild at least once a month so that too many changes don't pile up for us to handle all at once. Like I said, that was due to my hard drive being out of space. If you can believe it, my Linux-boxen only had a 6 GB hard drive. I have since upgraded it to a 20 GB hard drive. Hmm... along those lines... does anyone have any AGP video cards, 20 GB+ 7200 RPM hard drives, 256 MB PC133 SDRAM's, Pentium 3 550 MHz+ CPU's, Pentium 4's of any variety, P3 and P4 motherboards, Athlon XP 1700+, Athlon XP motherboards, or any other such hardware that they need to offload??? Just checking. You know, cause I could spend more time on Cygwin/XFree86 if I didn't have to spend so much time healing after the battle with the fiance everytime I spend money on computer parts (which isn't often, because I am starting to learn). Remember, I am a poor college student. Harold
Re: Using the new cross compilation system - and a request for help
Alexander Gottwald [EMAIL PROTECTED] said: On Thu, 11 Jul 2002, Harold L Hunt wrote: Alexander, Unfortunately, we still have to #undef i686. I just tried removing the ``#undef i686'' and the results are below. The problem is that the value for the i686 define is still being substituted into our includes path. Any ideas? That define is only used, if i686 is already used. For me imakemdep_cpp.h is generated this way /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; with ./ccimake just echoing -DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin -DCROSSCOMPILE -O can you please check, from where the i686 define gets into the imakemdep generation? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Alexander, I now have the following in host.def: /* * Point to our Cygwin headers that we copied over. */ #define PreIncDir #define StdIncDir /cygwin/i686-pc-cygwin/include #define ExtraIncDir /cygwin/i686-pc-cygwin/include/w32api Notice that I have put quotes around the StdIndDir and ExtraIncDir. This keeps the preprocessor from substituting ``1'' for i686. I'm doing a build right now and it didn't give any unfound header warnings during the makedepend phase, so I am thinking that this is a valid fix. Is there any reason that this would not be valid? Harold
Re: Using the new cross compilation system - and a request for help
On Thu, 11 Jul 2002, Nicholas Wourms wrote: Why is this naming convention being used? That is a relic of B20, we shouldn't use that anymore. Don't know. Once upon a time, i started building the crosscompile gcc, binutils and so on and catched the first name i could find. The cygwin target is called i686-pc-cygwin32 on my machine. It's just a simple name. For example, the SuSE folks used i486-suse-linux as name for their compile target, which is effectivly the same as i686-pc-linux-gnu (as it's called now on my machine). Don't think to long about this name, it's just used on my machine and in the rpms I created for the crosscompile gcc. bye ago BTW: With the new 64bit AMD processor, two different targets might exist i786-pc-cygwin32 and i786-pc-cygwin64 :) -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Using the new cross compilation system - and a request for help
On Thu, 11 Jul 2002, Harold L Hunt wrote: make CROSSCOMPILEDIR=/cygwin/bin World World.log 21 Are you talking about imakemdep_cpp.h being built during the World make, or are you doing this during a seperate step? It's build during make World. Here's a part from the log cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/scratch/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap rm -f imakemdep_cpp.h make[1]: Leaving directory `/scratch/xc/config/imake' make Makefile.boot make[1]: Entering directory `/scratch/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/scratch/xc/config/imake' making imake with BOOTSTRAPCFLAGS= and CROSSCOMPILEFLAGS=-DCROSSCOMPILEDIR=/usr/i686-pc-cygwin32/bin in config/imake cc -o ccimake -DCROSSCOMPILEDIR=\/usr/i686-pc-cygwin32/bin\ -O -I../../include -I../../imports/x11/include/X11 ccimake.c if [ -n /usr/i686-pc-cygwin32/bin ] ; then \ /usr/i686-pc-cygwin32/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; \ else touch imakemdep_cpp.h; fi cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c cc -o imake -O -I../../include -I../../imports/x11/include/X11 imake.o make[2]: Leaving directory `/scratch/xc/config/imake' somehow the cygwin-gcc got an extra define i686, either via commandline, include header or via predefines. That symbol i686 is never defined when I create the imakemdep_cpp.h How does the make log look for you? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Using the new cross compilation system - and a request for help
Alexander, So this seems to be normal. For cygwin, there is #ifdef __CYGWIN__ #define MacroIncludeFile cygwin.cf #define MacroFile cygwin.cf #define cygwinArchitecture #define i386Architecture #undef i386 #undef __i386__ #undef _X86_ #undef __CYGWIN__ #endif /* CYGWIN */ We just have to add #undef i686, #undef i486, #undef i586 here Excellent. I have applied just such a fix. Thank you for tracking this down. Now, regarding the imakemdep_cpp.h that I sent you, have you seen warnings similar to the ones I'm getting below? The reason I asked if your imakemdep_cpp.h was similar was because I wanted to know if it has those ``#1 imakedep_cpp.h'' lines like mine does. Harold make[5]: Entering directory `/home/harold/x-devel/build/newhostdef/config/util' rm -f rman.o gcc -c -I../.. -I../../exports/include -DVOLLIST='1:2:3:4:5:6:7:8:9:o:l :n:p' -DMANTITLEPRINTF='%s(%s) manual page' -DMANREFPRINTF='%s.%s.html' -DPOLYGLOTMANVERSION='3.0.8+XFree86' -DXFree86 rman.c rm -f rman gcc -I../../exports/include -o rman rman.o make[5]: Leaving directory `/home/harold/x-devel/build/newhostdef/config/util' okay, continuing in config/makedepend rm -f makedepend.1.html makedepend.1-html ../../config/util/rman -f HTML mkdepend._man \ makedepend.1-html mv -f makedepend.1-html makedepend.1.html macro UC not recognized -- ignoring make[4]: Leaving directory `/home/harold/x-devel/build/newhostdef/config/makedepend' okay, continuing in config/imake ../../config/makedepend/makedepend -- -I../../include -I../../exports/inclu de/X11 -I../.. -I../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN - DX_LOCALE -D_X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURCE=199309L -D_ BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DNO_ALLOCA -DFUNCPROTO=15 -DNARROW PROTO -DCPP_PROGRAM=\cpp\ -DHAS_MERGE_CONSTANTS=`if gcc -fmerge-constants -xc /dev/null -S -o /dev/null 2 /dev/null 1 /dev/null; then echo 1; else echo 0; fi` -DCROSSCOMPILE -DCROSSCOMPILEDIR=\/cygwin/bin\ -DUSE_MAKEDEPEND -- imake.c ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 1: unknown directive == # 1 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 37: unknown directive == # 191 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 187: unknown directive == # 398 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 222: unknown directive == # 446 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 235: unknown directive == # 466 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 246: unknown directive == # 500 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 258: unknown directive == # 547 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 260: unknown directive == # 568 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 287: unknown directive == # 610 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 298: unknown directive == # 644 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 311: unknown directive == # 667 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 318: unknown directive == # 688 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 321: unknown directive == # 699 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 344: unknown directive == # 869 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 420: unknown directive == # 1282 imakemdep.h ../../config/makedepend/makedepend: warning: imake.c (reading imakemdep_cpp.h), line 470: unknown directive == # 1341 imakemdep.h make[3]: Leaving directory `/home/harold/x-devel/build/newhostdef/config/imake' depending in config/makedepend... make[3]: Entering directory `/home/harold/x-devel/build/newhostdef/config/makedepend'
RE: Using the new cross compilation system - and a request for help
Alexander, I don't know if you ever explicity described how you got around the glibc_major and glibc_minor symbols not being defined. The fun error that I get is below. Harold Building Release 6.6 of the X Window System. I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Thu Jul 11 20:59:52 EDT 2002 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc clean make[1]: Entering directory `/home/harold/x-devel/build/newhostdef/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap rm -f imakemdep_cpp.h make[1]: Leaving directory `/home/harold/x-devel/build/newhostdef/config/imake' make Makefile.boot make[1]: Entering directory `/home/harold/x-devel/build/newhostdef' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=cc make[2]: Entering directory `/home/harold/x-devel/build/newhostdef/config/imake' making imake with BOOTSTRAPCFLAGS= and CROSSCOMPILEFLAGS=-DCROSSCOMPILEDIR=/cygwin/bin in config/imake cc -o ccimake -DCROSSCOMPILEDIR=\/cygwin/bin\ -O -I../../include -I../../import s/x11/include/X11 ccimake.c if [ -n /cygwin/bin ] ; then \ /cygwin/bin/cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; \ else touch imakemdep_cpp.h; fi cc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c imake.c: In function `define_os_defaults': imake.c:1503: `glibc_major' undeclared (first use in this function) imake.c:1503: (Each undeclared identifier is reported only once imake.c:1503: for each function it appears in.) imake.c:1505: `glibc_minor' undeclared (first use in this function) make[2]: *** [imake.o] Error 1 make[2]: Leaving directory `/home/harold/x-devel/build/newhostdef/config/imake' make[1]: *** [imake.proto] Error 2 make[1]: Leaving directory `/home/harold/x-devel/build/newhostdef' make: *** [World] Error 2
