Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make error installing on Mac OSX Yosemite #2

Open
bigtunacan opened this issue Feb 23, 2015 · 1 comment
Open

make error installing on Mac OSX Yosemite #2

bigtunacan opened this issue Feb 23, 2015 · 1 comment

Comments

@bigtunacan
Copy link

First I got the VEX error that I have seen others post. I got through that by cloning the vex repo here;
https://github.com/fredericgermain/vex

But then when I run make that errors out instead with the following.

In file included from ../include/pub_tool_clientstate.h:35:                                                                                                                        [229/1550]
../include/pub_tool_xarray.h:57:59: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
extern XArray* VG_(newXA) ( void*(*alloc_fn)(const HChar*,SizeT), 
                                                          ^~~~~
In file included from m_addrinfo.c:33:
./pub_core_clientstate.h:46:8: error: unknown type name 'Addr'
extern Addr  VG_(clstk_start_base); // *Initial* lowest byte address
       ^
./pub_core_clientstate.h:47:8: error: unknown type name 'Addr'
extern Addr  VG_(clstk_end);        // Highest byte address
       ^
./pub_core_clientstate.h:54:8: error: unknown type name 'Addr'
extern Addr  VG_(brk_base);      // start of brk
       ^
./pub_core_clientstate.h:55:8: error: unknown type name 'Addr'
extern Addr  VG_(brk_limit);     // current brk
       ^
./pub_core_clientstate.h:88:8: error: unknown type name 'Addr'
extern Addr VG_(client___libc_freeres_wrapper);
       ^
./pub_core_clientstate.h:94:8: error: unknown type name 'Addr'
extern Addr VG_(client__dl_sysinfo_int80);
       ^
./pub_core_clientstate.h:113:8: error: unknown type name 'SizeT'; did you mean 'SSizeT'?
extern SizeT* VG_(client__stack_cache_actsize__addr);
       ^~~~~
       SSizeT
../include/pub_tool_basics.h:91:31: note: 'SSizeT' declared here
typedef  Word                 SSizeT;     // 32             64
                              ^
In file included from m_addrinfo.c:35:
In file included from ./pub_core_libcbase.h:40:
../include/pub_tool_libcbase.h:82:8: error: unknown type name 'SizeT'; did you mean 'SSizeT'?
extern SizeT  VG_(strlen)         ( const HChar* str );
       ^~~~~
       SSizeT
../include/pub_tool_basics.h:91:31: note: 'SSizeT' declared here
typedef  Word                 SSizeT;     // 32             64
                              ^
In file included from m_addrinfo.c:35:
In file included from ./pub_core_libcbase.h:40:
../include/pub_tool_libcbase.h:84:68: error: unknown type name 'SizeT'; did you mean 'SSizeT'?
extern HChar* VG_(strncat)        ( HChar* dest, const HChar* src, SizeT n );
                                                                   ^~~~~
                                                                   SSizeT
../include/pub_tool_basics.h:91:31: note: 'SSizeT' declared here
typedef  Word                 SSizeT;     // 32             64
                              ^
In file included from m_addrinfo.c:35:
In file included from ./pub_core_libcbase.h:40:
../include/pub_tool_libcbase.h:87:68: error: unknown type name 'SizeT'; did you mean 'SSizeT'?
extern HChar* VG_(strncpy)        ( HChar* dest, const HChar* src, SizeT ndest );
@bigtunacan
Copy link
Author

I also tried clearing out the vex fork listed in my original post and cloning from here instead https://github.com/svn2github/valgrind-vex, but this resulted in the following (albeit distinct) error output.

_main.o -MD -MP -MF .deps/libcoregrind_amd64_darwin_a-m_main.Tpo -c -o libcoregrind_amd64_darwin_a-m_main.o `test -f 'm_main.c' || echo './'`m_main.c
m_main.c:567:31: error: no member named 'iropt_register_updates' in 'VexControl'
         VG_(clo_vex_control).iropt_register_updates 
         ~~~~~~~~~~~~~~~~~~~~ ^
m_main.c:692:45: error: no member named 'iropt_register_updates' in 'VexControl'
                       VG_(clo_vex_control).iropt_register_updates,
                       ~~~~~~~~~~~~~~~~~~~~ ^
../include/pub_tool_options.h:169:8: note: expanded from macro 'VG_XACT_CLO'
      (qq_var) = (qq_val); \
       ^
m_main.c:696:45: error: no member named 'iropt_register_updates' in 'VexControl'
                       VG_(clo_vex_control).iropt_register_updates,
                       ~~~~~~~~~~~~~~~~~~~~ ^
../include/pub_tool_options.h:169:8: note: expanded from macro 'VG_XACT_CLO'
      (qq_var) = (qq_val); \
       ^
m_main.c:700:45: error: no member named 'iropt_register_updates' in 'VexControl'
                       VG_(clo_vex_control).iropt_register_updates,
                       ~~~~~~~~~~~~~~~~~~~~ ^
../include/pub_tool_options.h:169:8: note: expanded from macro 'VG_XACT_CLO'
      (qq_var) = (qq_val); \
       ^
m_main.c:704:45: error: no member named 'iropt_register_updates' in 'VexControl'
                       VG_(clo_vex_control).iropt_register_updates,
                       ~~~~~~~~~~~~~~~~~~~~ ^
../include/pub_tool_options.h:169:8: note: expanded from macro 'VG_XACT_CLO'
      (qq_var) = (qq_val); \
       ^
5 errors generated.
make[3]: *** [libcoregrind_amd64_darwin_a-m_main.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

svn2github pushed a commit that referenced this issue Mar 14, 2015
The difference of the expected results as compared to other
platforms is

- Location 0x........ is 2 bytes inside local var "budget"
- declared at varinfo6.c:3115, in frame #2 of thread 1
+ Address 0x........ is on thread 1's stack
+ in frame #2, created by BZ2_blockSort (varinfo6.c:3107)

Should the stderr output of this testcase in the future 
match the generic output (varinfo6.stderr.exp) then this is
another incarnation of 
https://bugs.kde.org/show_bug.cgi?id=345121


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15011 a5019735-40e9-0310-863c-91ae7b9d1cf9
jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue Mar 16, 2015
The difference of the expected results as compared to other
platforms is

- Location 0x........ is 2 bytes inside local var "budget"
- declared at varinfo6.c:3115, in frame svn2github#2 of thread 1
+ Address 0x........ is on thread 1's stack
+ in frame svn2github#2, created by BZ2_blockSort (varinfo6.c:3107)

Should the stderr output of this testcase in the future 
match the generic output (varinfo6.stderr.exp) then this is
another incarnation of 
https://bugs.kde.org/show_bug.cgi?id=345121


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15011 a5019735-40e9-0310-863c-91ae7b9d1cf9
jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue Mar 19, 2015
The difference of the expected results as compared to other
platforms is

- Location 0x........ is 2 bytes inside local var "budget"
- declared at varinfo6.c:3115, in frame svn2github#2 of thread 1
+ Address 0x........ is on thread 1's stack
+ in frame svn2github#2, created by BZ2_blockSort (varinfo6.c:3107)

Should the stderr output of this testcase in the future 
match the generic output (varinfo6.stderr.exp) then this is
another incarnation of 
https://bugs.kde.org/show_bug.cgi?id=345121


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15011 a5019735-40e9-0310-863c-91ae7b9d1cf9
jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue Mar 20, 2015
The difference of the expected results as compared to other
platforms is

- Location 0x........ is 2 bytes inside local var "budget"
- declared at varinfo6.c:3115, in frame svn2github#2 of thread 1
+ Address 0x........ is on thread 1's stack
+ in frame svn2github#2, created by BZ2_blockSort (varinfo6.c:3107)

Should the stderr output of this testcase in the future 
match the generic output (varinfo6.stderr.exp) then this is
another incarnation of 
https://bugs.kde.org/show_bug.cgi?id=345121


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15011 a5019735-40e9-0310-863c-91ae7b9d1cf9
jvesely pushed a commit to ysarch-lab/valgrind that referenced this issue May 20, 2015
This allows to attach to Valgrind when VAlgrind is blocked in a syscall
and have GDB producing a stacktrace, rather than being unable
to unwind.
I.e. instead of having:
  (gdb) bt
  #0  0x380460f2 in do_syscall_WRK ()
  (gdb) 
with the directives, we obtain:
   (gdb) bt
   #0  vgPlain_mk_SysRes_x86_linux (val=1) at m_syscall.c:65
   svn2github#1  vgPlain_do_syscall (sysno=168, a1=944907996, a2=1, a3=4294967295, a4=0, a5=0, a6=0, a7=0, a8=0) at m_syscall.c:791
   svn2github#2  0x38031986 in vgPlain_poll (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1) at m_libcfile.c:535
   svn2github#3  0x3807479f in vgPlain_poll_no_eintr (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1)
       at m_gdbserver/remote-utils.c:86
   svn2github#4  0x380752f0 in readchar (single=4096) at m_gdbserver/remote-utils.c:938
   svn2github#5  0x38075ae3 in getpkt (buf=0x61f35020 "") at m_gdbserver/remote-utils.c:997
   svn2github#6  0x38076fcb in server_main () at m_gdbserver/server.c:1048
   svn2github#7  0x38072af2 in call_gdbserver (tid=1, reason=init_reason) at m_gdbserver/m_gdbserver.c:721
   #8  0x380735ba in vgPlain_gdbserver (tid=1) at m_gdbserver/m_gdbserver.c:788
   #9  0x3802c6ef in do_actions_on_error (allow_db_attach=<optimized out>, err=<optimized out>) at m_errormgr.c:532
   #10 pp_Error (err=0x61f580e0, allow_db_attach=1 '\001', xml=1 '\001') at m_errormgr.c:644
   #11 0x3802cc34 in vgPlain_maybe_record_error (tid=1643479264, ekind=8, a=2271560481, s=0x0, extra=0x62937f1c)
       at m_errormgr.c:851
   #12 0x38028821 in vgMemCheck_record_free_error (tid=1, a=2271560481) at mc_errors.c:836
   #13 0x38007b65 in vgMemCheck_free (tid=1, p=0x87654321) at mc_malloc_wrappers.c:496
   #14 0x3807e261 in do_client_request (tid=1) at m_scheduler/scheduler.c:1840
   #15 vgPlain_scheduler (tid=1) at m_scheduler/scheduler.c:1406
   #16 0x3808b6b2 in thread_wrapper (tidW=<optimized out>) at m_syswrap/syswrap-linux.c:102
   #17 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:155
   #18 0x00000000 in ?? ()
   (gdb) 




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15194 a5019735-40e9-0310-863c-91ae7b9d1cf9
cdleonard pushed a commit to cdleonard/valgrind that referenced this issue Nov 26, 2015
This allows to attach to Valgrind when VAlgrind is blocked in a syscall
and have GDB producing a stacktrace, rather than being unable
to unwind.
I.e. instead of having:
  (gdb) bt
  #0  0x380460f2 in do_syscall_WRK ()
  (gdb) 
with the directives, we obtain:
   (gdb) bt
   #0  vgPlain_mk_SysRes_x86_linux (val=1) at m_syscall.c:65
   svn2github#1  vgPlain_do_syscall (sysno=168, a1=944907996, a2=1, a3=4294967295, a4=0, a5=0, a6=0, a7=0, a8=0) at m_syscall.c:791
   svn2github#2  0x38031986 in vgPlain_poll (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1) at m_libcfile.c:535
   svn2github#3  0x3807479f in vgPlain_poll_no_eintr (fds=0x385226dc <remote_desc_pollfdread_activity>, nfds=1, timeout=-1)
       at m_gdbserver/remote-utils.c:86
   svn2github#4  0x380752f0 in readchar (single=4096) at m_gdbserver/remote-utils.c:938
   svn2github#5  0x38075ae3 in getpkt (buf=0x61f35020 "") at m_gdbserver/remote-utils.c:997
   svn2github#6  0x38076fcb in server_main () at m_gdbserver/server.c:1048
   svn2github#7  0x38072af2 in call_gdbserver (tid=1, reason=init_reason) at m_gdbserver/m_gdbserver.c:721
   #8  0x380735ba in vgPlain_gdbserver (tid=1) at m_gdbserver/m_gdbserver.c:788
   #9  0x3802c6ef in do_actions_on_error (allow_db_attach=<optimized out>, err=<optimized out>) at m_errormgr.c:532
   #10 pp_Error (err=0x61f580e0, allow_db_attach=1 '\001', xml=1 '\001') at m_errormgr.c:644
   #11 0x3802cc34 in vgPlain_maybe_record_error (tid=1643479264, ekind=8, a=2271560481, s=0x0, extra=0x62937f1c)
       at m_errormgr.c:851
   #12 0x38028821 in vgMemCheck_record_free_error (tid=1, a=2271560481) at mc_errors.c:836
   #13 0x38007b65 in vgMemCheck_free (tid=1, p=0x87654321) at mc_malloc_wrappers.c:496
   #14 0x3807e261 in do_client_request (tid=1) at m_scheduler/scheduler.c:1840
   #15 vgPlain_scheduler (tid=1) at m_scheduler/scheduler.c:1406
   #16 0x3808b6b2 in thread_wrapper (tidW=<optimized out>) at m_syswrap/syswrap-linux.c:102
   #17 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:155
   #18 0x00000000 in ?? ()
   (gdb) 




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15194 a5019735-40e9-0310-863c-91ae7b9d1cf9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant