Solaris lacks endian.h, so we'll need to use something like AC_C_BIGENDIAN in autoconf to find out what the endianness of the host platform is. There's a known issue that gives cross compilers trouble, but I'll set up md5.c so that endian.h is used first, otherwise the direct testing of the host.
I'll fix it all up this evening. Aaron ""Aaron Stone"" <[EMAIL PROTECTED]> said: > I'm getting the adb... on both the Opteron and my Pentium, both with > typedef unsigned int uint32 > > So I wonder if we have an endianness issue, too... I've got a Sparc at school, > I'll give it a whirl on that machine, too. And my Alpha is out of reach again, > so I can't double check the results on it :-( > > Aaron > > > ""Leif Jackson"" <[EMAIL PROTECTED]> said: > > > odd, just checked with your same chars pasted into the test app: > > > > ------------ > > jsdf;kljasdf > > asdf > > > > ------------ > > sun sparc 64 (no change to header) > > dc0778f4e49bd14622a016e705cbdb15 > > changed header: > > 0988915eac85ce5fed09f29252b0cc7f > > sun sparc 32 bit (no header change) > > 0988915eac85ce5fed09f29252b0cc7f > > linux 32 bit > > adb3013a42bdec7987a807bc750b47d5 > > linux 32 bit md5sum command on file with only the 2 lines plus the blank > > line: > > adb3013a42bdec7987a807bc750b47d5 > > > > I would say this askes the question is any md5 value we are getting from > > other archs valid? what did you get from your alpha for the sum? I guess > > this needs to be a str array to make sure.. I will write it up. thx. > > > > Thanks, > > Leif > > > > > > > > > well that makes sence. I belive solaris figures out the uint32 as it is > > > really emulating 32bits on the 64bit kernel. I did some reading and it > > > seems that dbmail as a whole may not benifit much from accualy being > > > compiled 64bit, in fact it may make it slower. What is your test showing? > > > I am glad at least we figured it out. I guess we could agree on some test > > > data and compile it into testmd5.c instead of using stdin and then we can > > > make sure the md5 is correct on the diff arch and 64bit vs 32bit? > > > > > > -leif > > > > > > > > >> Fixed. Turned out to be quite simple: > > >> > > >> In md5.h, find the #ifdef __alpha and change it to this: > > >> > > >> #if (defined(__alpha) || defined(__x86_64__)) > > >> typedef unsigned int uint32; > > >> #else > > >> typedef unsigned long uint32; > > >> #endif > > >> > > >> For whatever reason, the Sparc is still using a 32-bit int? Or perhaps > > >> it > > >> is > > >> not crashing but still giving wrong results? Being a big endian machine, > > >> there > > >> is an additional byte order reversing routine that kicks in on the > > >> Sparc; > > >> perhaps the side effect of which is not crashing? Also, clearly, we now > > >> know > > >> why my Alpha produced proper results... it was already hacked to work > > >> ;-) > > >> > > >> The correct way to handle this is with a sizeof test from configure, and > > >> an > > >> appropriate entry in config.h to give hints to word-size sensitive code. > > >> I'll > > >> make the appropriate changes this weekend :-) > > >> > > >> Aaron > > >> > > >> > > >> "Aaron Stone" <[EMAIL PROTECTED]> said: > > >> > > >>> Works in 32 bit mode. Also, the resulting md5 is different... > > >>> > > >>> There are a couple of compiler warnings in header.c regarding size_t > > >>> arguments to printf; basically, there's a different size_t size in > > >>> effect, > > >>> and of course a different pointer size, too. So either GCC is > > >>> generating > > >>> faulty 64-bit code on the Opteron, or there's just a simple > > >>> 64-bit-unclean > > >>> portion of the md5 code that isn't generating any warnings but sure is > > >>> mucking up the output. > > >>> > > >>> Aaron > > >>> > > >>> > > >>> [EMAIL PROTECTED]:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5 > > >>> testmd5.c *o > > >>> [EMAIL PROTECTED]:~/dbmail-2.0rc3> file *o testmd5 > > >>> dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), > > >>> not > > >> stripped > > >>> debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), > > >>> not > > >> stripped > > >>> header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), > > >>> not > > >> stripped > > >>> md5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), > > >>> not > > >> stripped > > >>> testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), > > >>> dynamically linked (uses shared libs), not stripped > > >>> [EMAIL PROTECTED]:~/dbmail-2.0rc3> ./testmd5 > > >>> ;lkajsdf;kljasdf > > >>> asdf > > >>> > > >>> 0a8c8e4fd15849ec600d9aac8e53bf93 > > >>> [EMAIL PROTECTED]:~/dbmail-2.0rc3> > > >>> > > >>> > > >>> "Leif Jackson" <[EMAIL PROTECTED]> said: > > >>> > > >>> > > > >>> > Humm well it isn't our code that's not 64bit clean, as I emailed in > > >>> the > > >>> > previous message, try compiling just thouse objects with -m32 or the > > >>> equiv > > >>> > if you can and see what happens. > > >>> > > > >>> > -leif > > >>> > > > >>> > > Looks like 64 bit by default on the Opteron... > > >>> > > > > >>> > > [EMAIL PROTECTED]:~/dbmail-2.0rc3> file *o testmd5 > > >>> > > dbmd5.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > > >>> not > > >>> > > stripped > > >>> > > debug.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > > >>> not > > >>> > > stripped > > >>> > > header.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > > >>> not > > >>> > > stripped > > >>> > > md5.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), > > >>> not > > >>> > > stripped > > >>> > > testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), > > >>> > > dynamically > > >>> > > linked (uses shared libs), not stripped > > >>> > > > > >>> > > > > >>> > > ""Leif Jackson"" <[EMAIL PROTECTED]> said: > > >>> > > > > >>> > >> > Valgrind emulates a Pentium instruction set, so it's not useful > > >>> on an > > >>> > >> > x86-64 > > >>> > >> > processor. They have gdb 5.3 installed, and I just compiled gdb > > >>> 6.0 > > >>> > >> for > > >>> > >> > myself, both of which give me this when I try to read the > > >>> backtrace: > > >>> > >> > > > >>> > >> > > >>> > >> Make sence on valgrind... hey does the gcc on an operton default > > >>> to > > >>> a > > >>> > >> 64bit linking or do you have to do something like -64 for all the > > >>> > >> objects? > > >>> > >> I am thinking about sun and gcc for example where you cannot > > >>> compile 64 > > >>> > >> bit without explicity telling the linker to link the 64 bit libs. > > >>> Just a > > >>> > >> thought I know sun solaris is totaly diffrent than linux on > > >>> operton. If > > >>> > >> it > > >>> > >> is accessing a 64bit NULL value, but only after completing the > > >>> output > > >>> > >> from > > >>> > >> md5. very odd... I will check this on a sun after compiling 64bit. > > >>> will > > >>> > >> let you know in a sec. on sun 32bit it works just find. > > >>> > >> > > >>> > >> -leif > > >>> > >> > > >>> > >> > > >>> > >> > [EMAIL PROTECTED]:~/gdb-6.0> ./gdb/gdb > > >>> > >> > GNU gdb 6.0 > > >>> > >> > Copyright 2003 Free Software Foundation, Inc. > > >>> > >> > GDB is free software, covered by the GNU General Public License, > > >>> and > > >>> > >> you > > >>> > >> > are > > >>> > >> > welcome to change it and/or distribute copies of it under > > >>> certain > > >>> > >> > conditions. > > >>> > >> > Type "show copying" to see the conditions. > > >>> > >> > There is absolutely no warranty for GDB. Type "show warranty" > > >>> for > > >>> > >> > details. > > >>> > >> > This GDB was configured as "x86_64-unknown-linux-gnu". > > >>> > >> > (gdb) file ../dbmail-2.0rc3/testmd5 > > >>> > >> > Reading symbols from ../dbmail-2.0rc3/testmd5...done. > > >>> > >> > (gdb) run > > >>> > >> > Starting program: > > >>> /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 > > >>> > >> > ;lkajsdf;kljasdf > > >>> > >> > asdf > > >>> > >> > > > >>> > >> > b3dd95bad20e039aa898a75cdab51a4d > > >>> > >> > > > >>> > >> > Program received signal SIGSEGV, Segmentation fault. > > >>> > >> > 0x0000000000000000 in ?? () > > >>> > >> > > > >>> > >> > > > >>> > >> > ""Leif Jackson"" <[EMAIL PROTECTED]> said: > > >>> > >> > > > >>> > >> >> Aaron, > > >>> > >> >> > > >>> > >> >> I would try valgrind, they should have it installed. It does > > >>> well on > > >>> > >> >> all > > >>> > >> >> kinds of bounds checking, as well as memory and cache checks. > > >>> > >> >> > > >>> > >> >> -Leif > > >>> > >> >> > > >>> > >> >> > > > >>> > >> >> > Hey, > > >>> > >> >> > > > >>> > >> >> > So I whipped up a little wrapper program around read_header() > > >>> and > > >>> > >> >> > makemd5() > > >>> > >> >> > that crashes on the Opteron server at SourceForge, but works > > >>> > >> properly > > >>> > >> >> on > > >>> > >> >> > my > > >>> > >> >> > Pentium. > > >>> > >> >> > > > >>> > >> >> > Just one problem: what tools can I use to debug this thing on > > >>> > >> >> Opteron!? > > >>> > >> >> > > > >>> > >> >> > I've attached my test program. It compiles in the dbmail > > >>> build > > >>> > >> tree, > > >>> > >> >> like > > >>> > >> >> > so: > > >>> > >> >> > > > >>> > >> >> > gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o > > >>> debug.o > > >>> > >> >> > > > >>> > >> >> > Aaron > > >>> > >> >> > > > >>> > >> >> > > >>> > >> >> _______________________________________________ > > >>> > >> >> Dbmail-dev mailing list > > >>> > >> >> [email protected] > > >>> > >> >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >>> > >> >> > > >>> > >> > > > >>> > >> > > > >>> > >> > > > >>> > >> > -- > > >>> > >> > > > >>> > >> > > > >>> > >> > > > >>> > >> > _______________________________________________ > > >>> > >> > Dbmail-dev mailing list > > >>> > >> > [email protected] > > >>> > >> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >>> > >> > > > >>> > >> > > >>> > >> _______________________________________________ > > >>> > >> Dbmail-dev mailing list > > >>> > >> [email protected] > > >>> > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >>> > >> > > >>> > > > > >>> > > > > >>> > > > > >>> > > -- > > >>> > > > > >>> > > > > >>> > > > > >>> > > _______________________________________________ > > >>> > > Dbmail-dev mailing list > > >>> > > [email protected] > > >>> > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >>> > > > > >>> > > > >>> > _______________________________________________ > > >>> > Dbmail-dev mailing list > > >>> > [email protected] > > >>> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >>> > > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Dbmail-dev mailing list > > >>> [email protected] > > >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >>> > > >> > > >> > > >> > > >> -- > > >> > > >> > > >> > > >> _______________________________________________ > > >> Dbmail-dev mailing list > > >> [email protected] > > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >> > > > > > > _______________________________________________ > > > Dbmail-dev mailing list > > > [email protected] > > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > -- > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
