search

stlukey / homebrew-valgrind-mojave

An unofficial tap that adds Mojave support to valgrind.
17 stars 0 forks source link

Undefined symbols "_mach_msg_destroy" #2

Open ShawnZhong opened 5 years ago

ShawnZhong commented 5 years ago

I got the following error message while installing Valgrind via brew tap o4dev/homebrew-valgrind-mojave && brew install valgrind-mojave

==> make Last 15 lines from /Users/Shawn/Library/Logs/Homebrew/valgrind-mojave/02.make: Undefined symbols for architecture x86_64: "_mach_msg_destroy", referenced from: kernelrpc_mach_vm_allocate in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) __kernelrpc_mach_vm_deallocate in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) kernelrpc_mach_vm_protect in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) _mach_vm_inherit in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) __kernelrpc_mach_vm_read in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) _mach_vm_read_list in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) _mach_vm_write in libcoregrind-amd64-darwin.a(libcoregrind_amd64_darwin_a-mach_vmUser.o) ... ld: symbol(s) not found for architecture x86_64 make[3]: [memcheck-amd64-darwin] Error 1 make[2]: [all-recursive] Error 1 make[1]: [all-recursive] Error 1 make: [all] Error 2

Does anyone know why? Thanks!

Shandem commented 5 years ago

I got the same error. please help

retX0 commented 5 years ago

same issue, any idea?

samuelsit commented 5 years ago

same issue

BodaThomas commented 5 years ago

same

ste7en commented 5 years ago

same error

iFredOS commented 5 years ago

Same issue.

DiffeoInvariant commented 5 years ago

I have the same issue. I looked in the auto-generated makefile, and it looks like it should be removing all the files that are giving this error near the bottom of the file (there's a rm -f [list of stuff for AMD architectures], but it doesn't look like it's working (to remove the files) for some reason. I would change it to rm -rf and see if that works instead, but because of the way homebrew works, the auto-generated makefiles are not user-executable, even if you chmod +x them.

ste7en commented 5 years ago

@DiffeoInvariant could you test it modifying the lines you mentioned without homebrew?

DiffeoInvariant commented 5 years ago

@ste7en No, I don't think so. They're auto-generated makefiles, so they can't be generated without Homebrew, and when I tried to execute them, they couldn't be executed, even after enabling all permissions. If you have any ideas on how I might circumvent that, I'll try them. In the meanwhile though, I'm just going to set up a linux vm to do all my valgrind use...

ste7en commented 5 years ago

@DiffeoInvariant I don't know if, changing the Makefile lines you're referring to, will solve the problem. Anyway, I managed to install Valgrind on my macOS Mojave 10.14.5 .

Before explaining the solution, this is also a valid alternative I've worked with for months: • install Valgrind on a linux docker image • run it adding 

valgrind() {
        docker run --rm -i -t -v "$PWD":/tmp 'docker-image-name' valgrind --leak-check=full "$@"
}

to your .bash_profile file.

Instead, I found a working solution downloading the Valgrind-Mojave tar file specified in valgrind-mojave.rb homebrew file of this repository. Before installing it, download the Command Line Tools (macOS 10.13) for Xcode 9.4.dmg from Apple Developer website (here) and install it.

Now, to install Valgrind tools: • extract the Valgrind tar file (tar -xjf valgrind-mojave-3.14-unoffical.tar.bz2) • run ./configure --enable-only64bit • make • make install

Et voilà, a working Valgrind environment for macOS Mojave. The problem is that, from Xcode 10 and its command line tools, the 10.14 SDK, there's no longer multi-arch support but only x86_64.

witaly-iwanow commented 5 years ago

It seems like you need to create a stub for mach_msg_destroy: https://www.mail-archive.com/kde-bugs-dist@kde.org/msg363378.html I used that guy's formula, it builds fine, but valgrind itself (memcheck in my case) is very slow on macOS compared to Ubuntu and returns a bunch of bogus error messages. I'm done messing around with valgrind on macOS, but it might work for other people on simple code base

HenriBrg commented 5 years ago

I found a working solution to use VALGRIND on my Mac (Mojave 10.14.6). Just run this command :

brew install --HEAD https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/valgrind.rb

(From https://github.com/LouisBrunner/valgrind-macos)

Hope it will work for you.

iFredOS commented 5 years ago

I found a working solution to use VALGRIND on my Mac (Mojave 10.14.6). Just run this command :

brew install --HEAD https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/valgrind.rb

(From https://github.com/LouisBrunner/valgrind-macos)

Hope it will work for you.

THANK YOU! 🤓

americachambers commented 4 years ago

@HenriBrg THANK YOU, THANK YOU, THANK YOU!

Napoleon-BlownApart commented 4 years ago

I have the same issue as the OP and no fix yet. I am still running MacOS 10.14.5 and Xcode 10.2. (I cannot/will not upgrade to Catalina as I have 32bit apps which I cannot do without.)

@witaly-iwanow : could you please explain what you mean by create a stub for mach_msg_destroy? I've looked at the mail archive and it appears to me that Louis does not indicate what the fix actually is. I cloned his repo and tried to build it, but the build fails at an obscure point and strange reason:

    gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub -I../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1 -DVGPV_amd64_darwin_vanilla=1  -Ipriv   -arch x86_64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wimplicit-fallthrough=2 -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin  -mmacosx-version-min=10.6  -Wbad-function-cast -fstrict-aliasing  -MT priv/libvexmultiarch_amd64_darwin_a-multiarch_main_main.o -MD -MP -MF priv/.deps/libvexmultiarch_amd64_darwin_a-multiarch_main_main.Tpo -c -o priv/libvexmultiarch_amd64_darwin_a-multiarch_main_main.o `test -f 'priv/multiarch_main_main.c' || echo './'`priv/multiarch_main_main.c
    mv -f priv/.deps/libvexmultiarch_amd64_darwin_a-multiarch_main_main.Tpo priv/.deps/libvexmultiarch_amd64_darwin_a-multiarch_main_main.Po
    rm -f libvexmultiarch-amd64-darwin.a
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cru libvexmultiarch-amd64-darwin.a priv/libvexmultiarch_amd64_darwin_a-multiarch_main_main.o
    ranlib libvexmultiarch-amd64-darwin.a
    Making all in coregrind
    (cd m_mach && mig /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/task.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/thread_act.defs /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/vm_map.defs)
    /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs:75:10: fatal error: 'mach/std_types.defs' file not found
    #include <mach/std_types.defs>
             ^~~~~~~~~~~~~~~~~~~~~
    1 error generated.
    "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs", line 101: type 'vm_task_entry_t' not defined
    "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs", line 102: type 'mach_vm_address_t' not defined
    "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs", line 103: type 'mach_vm_size_t' not defined
    "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs", line 104: type 'int' not defined
    mig: fatal: "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs", line 104: 4 errors found. Abort.

    make[2]: *** [m_mach/mach_vmUser.c] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

I say strange because mach_vm.defs and std_types.defs are in the same folder (and both exist). I haven't had this error before, as usually it's either the make target problem or the undefined symbol _mach_msg_destroy issue. I have two Valgrind repos and will see if I can find the source of this particular problem by comparing them with Meld (one of my 32bit apps).

Napoleon-BlownApart commented 4 years ago

I've worked it out... There are three things you need to check/correct.

The first thing to do is insert #define __private_extern__ extern immediately after the file description comments in the following source files:

The second thing that needs to be done is to insert the stub that @witaly-iwanow mentioned, at the bottom of coregrind/m_mach/mach_msg.c (just above the line #endif // defined(VGO_darwin)). After editing coregrind/m_mach/mach_msg.c, the tail should look something like the following:

void
mach_msg_destroy(mach_msg_header_t *msg)
{
  // TODO: copy from XNU?
}

#endif // defined(VGO_darwin) 

/*--------------------------------------------------------------------*/
/*--- end                                                          ---*/
/*--------------------------------------------------------------------*/

observation: coregrind/m_mach/mach_msg.c looks a bit skimpy compared to Apple's version. Instead of having an empty stub for mach_msg_destroy, maybe Apple's code could be dropped in? I haven't tested this yet.

The third step is to update the Makefiles. Since MacOS, under Mojave (10.14.5) does not have a /usr/include folder, GCC (Apple's version) cannot find the *.def files it needs. As a result, there are two Automake/Make related updates that are needed. (See below for a more robust way of doing this.)

Updating coregrind/Makefile.am to simplify the 3nd step. (Note that you still need to do steps 1 and 2, but only once.)

Step 3 above can be a hassle, error prone, and too much like a 'hack', especially if you want/need to repeat the build steps after cleaning.... A better way, in my opinion, is to make the necessary changes directly in coregrind/Makefile.am, once, and autogen.sh will insert the necessary and correct changes for you.
Doing it this way requires creating a new variable in codegrind/Makefile.am and then using it further below. I've pasted the entire Darwin Mach stuff section of codegrind/Makefile.am below, and marked, using <==< comment where you need to make the changes. Note that the recipes mentioned above now use $(macosx_sdk) in the include switch instead of a hard-coded path. With this version of step 3, you can safely do a make distclean immediately followed by autogen.sh, ./configure --enable-only64bit, make, make install.


#----------------------------------------------------------------------------
# Darwin Mach stuff
#----------------------------------------------------------------------------

# Mach RPC interface definitions
# Here are some more .defs files that are not used, but could be in the
# future:
#    clock.defs \
#    clock_priv.defs \
#    clock_reply.defs \
#    exc.defs \
#    host_priv.defs \
#    host_security.defs \
#    ledger.defs \
#    lock_set.defs \
#    mach_host.defs \
#    mach_port.defs \
#    notify.defs \
#    processor.defs \
#    processor_set.defs \
#
macosx_sdk = $(shell xcrun --show-sdk-path)         <==< ADD new variable here
$(info 'macosx_sdk' PATH = $(macosx_sdk))           <==< (Optional) prints the path in the console
mach_user_srcs =
mach_server_srcs =
mach_hdrs =
mach_defs =
if VGCONF_OS_IS_DARWIN
mach_user_srcs += \
    m_mach/mach_vmUser.c \
    m_mach/taskUser.c \
    m_mach/thread_actUser.c \
    m_mach/vm_mapUser.c
mach_server_srcs += \
    m_mach/mach_vmServer.c \
    m_mach/taskServer.c \
    m_mach/thread_actServer.c \
    m_mach/vm_mapServer.c
mach_hdrs += \
    m_mach/mach_vm.h \
    m_mach/task.h \
    m_mach/thread_act.h \
    m_mach/vm_map.h
mach_defs += \                                    
    $(macosx_sdk)/usr/include/mach/mach_vm.defs \       <==<  Use the new variable here.
    $(macosx_sdk)/usr/include/mach/task.defs \
    $(macosx_sdk)/usr/include/mach/thread_act.defs \
    $(macosx_sdk)/usr/include/mach/vm_map.defs
endif

# Be careful w.r.t. parallel builds.  See section 27.9 of the automake info
# page, "Handling Tools that Produce many Outputs".
$(abs_builddir)/m_mach: 
    mkdir -p $@
$(mach_user_srcs): $(mach_defs) $(abs_builddir)/m_mach
    (cd m_mach && mig -I$(macosx_sdk)/usr/include $(mach_defs))         <==<  Use the new variable here.
$(mach_hdrs): $(mach_defs) $(mach_user_srcs) $(abs_builddir)/m_mach
    (cd m_mach && mig -I$(macosx_sdk)/usr/include $(mach_defs))         <==<  Use the new variable here.

You may also want to print out the path in the console output, in which you can do so by putting $(info 'macosx_sdk' PATH = $(macosx_sdk)) straight after the line where you assign the xcrun output to macosx_sdk.

I actually used the repo @ https://github.com/Echelon9/valgrind (git checkout feature/v3.14/macos-mojave-support-v2) to build my install of valgrind. Whilst trying to get valgrind to compile, I managed to download 4 different repos and lost track of which was which. Echelon9's was the one I got working first. I'm posting here because this was the only valgrind repo on GitHub that allowed me to ask my earlier question, and later post this solution. The changes above should also be valid for this repo, but I confess I haven't checked.