On Fri, Aug 22, 2008 at 3:02 PM, Subrata Modak <[EMAIL PROTECTED]> wrote: > On Thu, 2008-08-21 at 15:35 +0000, Darren Hart wrote: >> On Thu, 2008-08-21 at 15:17 +0200, Daniel Gollub wrote: >> > On Thursday 21 August 2008 12:29:57 Chirag Jog wrote: >> > > Hi Daniel, >> > > * Daniel Gollub <[EMAIL PROTECTED]> [2008-08-20 15:05:00]: >> > > >> > > > On Thursday 24 July 2008 06:22:59 Darren Hart wrote: >> > > > > On Thu, 2008-07-24 at 05:06 +0530, Subrata Modak wrote: >> > > > > > On Mon, 2008-07-21 at 15:57 +0200, Gilles Carry wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > When compiling powerpc binaries, gcc defaults to 32 bit. >> > > > > > > To do some tests I needed to have a 64 bit binary. >> > > > > > > Since I'm using realtime, I modified config.mk as below. >> > > > > > > My questions: is there any official way to turn LTP in 64bit? >> > > > > > > If not, what shall we do then? Should LTP default to 32 or >> > > > > > > native-arch bit? >> > > > > > >> > > > > > It should default to native-arch bit. I hope the Makefile(s) take >> > > > > > care >> > > > > > of that stuff automatically. >> > > > > > >> > > > > > > Shall we use something like: "if (uname -m) ..." or use a >> > > > > > > command line >> > > > > > > option? >> > > > > > > Any comment? >> > > > > > > >> > > > > > > Gilles. >> > > > > > > >> > > > > > > >> > > > > > > diff --git a/testcases/realtime/config.mk >> > > > > > > b/testcases/realtime/config.mk >> > > > > > > index 19ccddc..083db58 100644 >> > > > > > > --- a/testcases/realtime/config.mk >> > > > > > > +++ b/testcases/realtime/config.mk >> > > > > > > @@ -23,3 +23,4 @@ LDLIBS += $(srcdir)/lib/libjvmsim.o \ >> > > > > > > $(srcdir)/lib/libstats.o \ >> > > > > > > -lpthread -lrt -lm >> > > > > > > >> > > > > > > +CFLAGS += -m64 >> > > > > >> > > > > According to man gcc: >> > > > > >> > > > > -m64 >> > > > > Generate code for a 32-bit or 64-bit environment. The >> > > > > 32-bit envi- >> > > > > ronment sets int, long and pointer to 32 bits and >> > > > > generates code >> > > > > that runs on any i386 system. The 64-bit environment >> > > > > sets int to >> > > > > 32 bits and long and pointer to 64 bits and generates >> > > > > code for >> > > > > AMD's x86-64 architecture. For darwin only the -m64 >> > > > > option turns >> > > > > off the -fno-pic and -mdynamic-no-pic options. >> > > > > >> > > > > This seems like the right thing to do to me. Gilles, have you >> > > > > confirmed that >> > > > > this doesn't break things on the x86_64 platforms? >> > > > > >> > > > > No objection from me. >> > > > >> > > > Unfortunately this breaks build on i586: >> > > > >> > > > + make -C testcases/realtime/ >> > > > make: Entering directory >> > > > `/usr/src/packages/BUILD/ltp-full-20080820/testcases/realtime' >> > > > make[1]: Entering directory >> > > > `/usr/src/packages/BUILD/ltp-full-20080820/testcases/realtime/lib' >> > > > cc -march=i586 -mtune=i686 -fmessage-length=0 -Wall >> > > > -D_FORTIFY_SOURCE=2 -fstack-protector -O2 -g -Wall -m64 -Wall -m64 >> > > > -I../include -D_GNU_SOURCE -c -o libjvmsim.o libjvmsim.c >> > > > libjvmsim.c:1: sorry, unimplemented: 64-bit mode not compiled in >> > > > make[1]: *** [libjvmsim.o] Error 1 >> > >> > Just did a quick check, it seems most 32bit gcc compiler have -m64 >> > disabled by default: >> > http://gcc.gnu.org/ml/gcc/2006-07/msg00603.html >> > >> > Not quite sure if this is reason enough to revert his... >> > >> > > > >> > > > What about adding -m64 only for ppc? >> > > Will this not cause a problem for ppc 32bit? >> > >> > At least it should build if you have 64bit build environment installed. >> > Gilles, instead of hardcoding -m64 for pcc - what about passing >> > CFLAGS="-m64" as >> > environment variable while building ltp-realtime? >> > >> > CFLAGS="-m64" make -C testcases/realtime >> > >> > This should work, since the CFLAGS variable gets never overwritten by >> > config.mk. >> > >> > >> > > > best regards, >> > > > Daniel >> > > > >> > > > --- >> > > > >> > > > diff --git a/testcases/realtime/config.mk >> > > > b/testcases/realtime/config.mk >> > > > index 083db58..046bd93 100644 >> > > > --- a/testcases/realtime/config.mk >> > > > +++ b/testcases/realtime/config.mk >> > > > @@ -23,4 +23,7 @@ LDLIBS += $(srcdir)/lib/libjvmsim.o \ >> > > > $(srcdir)/lib/libstats.o \ >> > > > -lpthread -lrt -lm >> > > > >> > > > -CFLAGS += -m64 >> > > > +ifeq ($(shell uname -m), ppc) >> > > This check could be for x86_64 and ppc64 ? >> > > > + CFLAGS += -m64 >> > > > +endif >> > > > + >> > > >> > >> > Not quite sure if it really makes sense to override the compilers >> > native-arch even >> > on ppc - i just wrote this patch to get i586 working again. Currently i >> > don't focus >> > on ppc, but this even restrict people to have 64bit build environment >> > installed. >> > >> > I would prefere that this is up to the person who build >> > ltp-realtime/packager by >> > passing some CFLAGS as environment variable. >> > >> > Thoughts? >> >> It seems to me that this should be automatic, and we should build 64 bit >> on 64bit platforms (over simplistic view, but just trying to state my >> goal). Also, we should aim for some consistency with the rest of LTP. >> How do other tests within LTP handle this scenario? Can we model our >> makefiles after those? > > Garrett, > > Can you answer Darren´s doubt ? > > Darren, > > Garrett is working on making all the LTP Makefile(s) much better. > > Regards-- > Subrata
It would be better to add these items to your starting CFLAGS (like CROSS_CFLAGS) so then it applies to everything. Adding another check to a Makefile for what the compiling individual should do is really stupid and limiting. Doing my first suggestion gives the individual more freedom to test 32-bit binaries on powerpc on the hybrid ppc64 kernel / ppc32 userland config (a usecase which should be done, n64), as well as the completely ppc64 environment (no 32-bit binaries, o64). Same goes for x86_64 hybrid (n64) vs non-x86 compat x86_64 (o64). This also doesn't create additional exceptions for mips (which has the same issues as I mentioned earlier with 32-bit and 64-bit hybrid and non-hybrid architectures). Someone else could make a case for other architectures (don't think this applies to arm/sparc though). If you really want to determine a machine's target build system, you could use $(CROSS_COMPILE)gcc -dumpmachine to get the 3-tuple config: [EMAIL PROTECTED] ~ $ gcc -dumpmachine i686-pc-linux-gnu Don't recommend this though because, again, this is limiting: [EMAIL PROTECTED] ~]$ /auto/nova/tools/latest/i686-pc-linux/bin/binos_c4.1.2.mips64-octeon-linux-gcc-4.1.2 -dumpmachine mips64-octeon-linux The second compiler supports o32, n32, and n64 compilation. Cheers, -Garrett ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
