On Saturday 23 August 2008 01:36:21 Garrett Cooper wrote: > 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.
Fully agree on this. Gilles, Darren, is there any objection to revert the "CFLAGS += -m64" line? Currently i have to patch this change out of the build environment to have a proper build on i586. Since -m64 just gets appended on the user-defined CLFAGS and there is no way to overwrite -m64 without touching the build environment. best regards, Daniel ------------------------------------------------------------------------- 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
