Re: [Valgrind-users] Valgrind newb here needs help ;-)

[David E. <da...@2g...>]

(It is not advisable to start a new topic by replying to an old mail.
Many mail agents threads messages so that this mail thread shows inside
of the "BerkeleyDB gets bogus errno in Valgrind" thread.)

On Wed, 2003-05-07 at 19:26, Tristan Van Berkom wrote:
> Hi everyone!
> 	I develop jukebox apliences under linux and am considering
> valgrind as a memory debugging tool. Personaly I do not have a vast
> knowlage
> on cpu's and all that jazz, acronymes et al so please bear with me.
> 
> 
> My questions are the following:
> 
>     Considering that gcc doesn't generate opcodes for anything other
> than i386 if not specified and that valgrind takes the i486 instruction
> set as a baseline:
> 
>         Would it be a fatal mistake to assume that valgrind will support
>     the i386 instruction set as a consiquence of supporting the i486
>     instruction set ((i486 >= i386) ? backwards compatible) ?
> 
>     or would I have to recompile all my code with `-march=i486' ?
> 
> ===================== from `info gcc' (-mcpu=option) ================
>      While picking a specific CPU TYPE will schedule things
>      appropriately for that particular chip, the compiler will not
>      generate any code that does not run on the i386 without the
>      `-march=CPU TYPE' option being used.  `i586' is equivalent to
>      `pentium' and `i686' is equivalent to `pentiumpro'.  `k6' is the
>      AMD chip as opposed to the Intel ones.
> =====================================================================

You don't have to compile your code for i486. Compiling for i386 is just
fine as the i386 instructions is a subset of the i486 instruction set.

>     I'm a real dunce when it comes to automake and friends ;-)
> I ran `./configure --prefix=/usr/local' followed by `make'.
> (after that I tried a slew of options such as --host, --build,
> --target all of which I cant seem to get right even while
> searching through the config.sub).

Just a note: /usr/local is the default prefix. If you want valgrind
installed with this prefix you don't need a single option to valgrind.

> This is the compile command issued by make that failed:
> ======================================================================
> source='vg_intercept.c' object='vg_intercept.o' libtool=no \
> depfile='.deps/vg_intercept.Po' tmpdepfile='.deps/vg_intercept.TPo' \
> depmode=gcc /bin/sh ../depcomp \
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include    
> -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O
> -fomit-frame-pointer -mpreferred-stack-boundary=2 -g
> -fno-omit-frame-pointer -c `test -f 'vg_intercept.c' || echo
> './'`vg_intercept.c
> 
> This is the error isued:
> =================================================
> vg_intercept.c:419: conflicting types for `msgsnd'
> /usr/include/sys/msg.h:74: previous declaration of `msgsnd'
> 
> and theese are the prototypes:
> ============ vg_intercept.c:419 =================
> #ifdef GLIBC_2_1
> int msgsnd(int msgid,       void *msgp, size_t msgsz, int msgflg)
> #else
> int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg)
> #endif
> 
> ============ /usr/include/sys/msg.h ============
> extern int msgsnd __P ((int __msqid, __const void *__msgp, size_t
> __msgsz,
>                         int __msgflg));
> 
> I have to admit that after 3 years of seeing this damn macro in header
> files I still haven't figured out exactly what it does (`__P') but I
> have
> a hunch that it removes some of theese leading underscores.
> 
> What I do find strange is that in my `msg.h' msgp is `const' and 
> that comes from GLIBC_2_1 !!! but if that conditional directive
> was buggy; nobody else would be able to compile valgrind either 
> (I think). (BTW, GLIBC_2_1 is defined in the config.h)
> 
> I am using:
> gcc          2.95.3
> Linux kernel 2.4.16
> glibc        2.1.3-5
> valgrind     1.9.6 (latest)
> (missing anything ?)
> 
> Any help with my compile situation is greatly apreciated.

After running ./configure, remove GLIBC_2_1 from config.h. This solution
is of course a hack, but you should at least be able to compile
valgrind.

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds