Recherche avancée

Sur d’autres sites (11057)

• Procedure entry point could not be found ?

  30 décembre 2012, par ronag

  I've encountered a strange problem. After updating to the latest ffmpeg headers/lib/dll I keep getting the error :

  The procedure entry point __glewProgramUniform1i could not be located in the dynamic link library

  If I change so that I link to glew using static linking, then that specific error disappears and it instead complains about some other procedure entry point in some other dll, and so on.

  As soon as a revert to the old ffmpeg headers/lib/dll the problem disappears.

  What could cause this behavior ? How do I debug this ?

  NOTE : This only happens during release builds, not during debug builds.

  

  

  Depends profile log :

  Started "CONHOST.EXE" (process 0x1BBC) at address 0x000007F63CF60000.  Successfully hooked module.
  
  Loaded "NTDLL.DLL" at address 0x000007F945C30000.  Successfully hooked module.
  
  Loaded "KERNEL32.DLL" at address 0x000007F943400000.  Successfully hooked module.
  
  Loaded "KERNELBASE.DLL" at address 0x000007F942D10000.  Successfully hooked module.
  
  DllMain(0x000007F942D10000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNELBASE.DLL" called.
  
  DllMain(0x000007F942D10000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNELBASE.DLL" returned 1 (0x1).
  
  DllMain(0x000007F943400000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNEL32.DLL" called.
  
  DllMain(0x000007F943400000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "KERNEL32.DLL" returned 1 (0x1).
  
  Injected "DEPENDS.DLL" at address 0x000000005ACD0000.
  
  DllMain(0x000000005ACD0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DEPENDS.DLL" called.
  
  DllMain(0x000000005ACD0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DEPENDS.DLL" returned 1 (0x1).
  
  Loaded "GDI32.DLL" at address 0x000007F945970000.  Successfully hooked module.
  
  Loaded "USER32.DLL" at address 0x000007F943860000.  Successfully hooked module.
  
  Loaded "MSVCRT.DLL" at address 0x000007F945430000.  Successfully hooked module.
  
  Loaded "IMM32.DLL" at address 0x000007F945320000.  Successfully hooked module.
  
  Loaded "OLEAUT32.DLL" at address 0x000007F9454E0000.  Successfully hooked module.
  
  Loaded "COMBASE.DLL" at address 0x000007F9457C0000.  Successfully hooked module.
  
  Loaded "MSCTF.DLL" at address 0x000007F944FD0000.  Successfully hooked module.
  
  Loaded "RPCRT4.DLL" at address 0x000007F944CF0000.  Successfully hooked module.
  
  Entrypoint reached. All implicit modules have been loaded.
  
  DllMain(0x000007F943860000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "USER32.DLL" called.
  
  DllMain(0x000007F945430000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSVCRT.DLL" called.
  
  DllMain(0x000007F945430000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSVCRT.DLL" returned 1 (0x1).
  
  DllMain(0x000007F943860000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "USER32.DLL" returned 1 (0x1).
  
  DllMain(0x000007F945970000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "GDI32.DLL" called.
  
  DllMain(0x000007F945970000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "GDI32.DLL" returned 1 (0x1).
  
  DllMain(0x000007F944FD0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSCTF.DLL" called.
  
  DllMain(0x000007F944FD0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "MSCTF.DLL" returned 1 (0x1).
  
  DllMain(0x000007F945320000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "IMM32.DLL" called.
  
  DllMain(0x000007F945320000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "IMM32.DLL" returned 1 (0x1).
  
  DllMain(0x000007F944CF0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "RPCRT4.DLL" called.
  
  DllMain(0x000007F944CF0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "RPCRT4.DLL" returned 1154577921 (0x44D17601).
  
  DllMain(0x000007F9457C0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "COMBASE.DLL" called.
  
  DllMain(0x000007F9457C0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "COMBASE.DLL" returned 1 (0x1).
  
  DllMain(0x000007F9454E0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "OLEAUT32.DLL" called.
  
  DllMain(0x000007F9454E0000, DLL_PROCESS_ATTACH, 0x00000019CF36F8C0) in "OLEAUT32.DLL" returned 1 (0x1).
  
  Loaded "UXTHEME.DLL" at address 0x000007F941950000.  Successfully hooked module.
  
  DllMain(0x000007F941950000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "UXTHEME.DLL" called.
  
  DllMain(0x000007F941950000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "UXTHEME.DLL" returned 1 (0x1).
  
  Error writing a breakpoint at the entrypoint return of "".  Entrypoint cannot be hooked. Invalid access to memory location (998).
  
  Loaded "" at address 0x00000019D1220000.  Successfully hooked module.
  
  Unloaded "" at address 0x00000019D1220000.
  
  Loaded "START8_64.DLL" at address 0x000007F93A130000.  Successfully hooked module.
  
  DllMain(0x000007F93A130000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "START8_64.DLL" called.
  
  GetProcAddress(0x000007F943860000 [USER32.DLL], "CreateWindowInBand") called from "START8_64.DLL" at address 0x000007F93A1C0941 and returned 0x000007F943872C20.
  
  LoadLibraryA("ADVAPI32.dll") called from "START8_64.DLL" at address 0x000007F93A1A1D5C.
  
  Loaded "ADVAPI32.DLL" at address 0x000007F944E40000.  Successfully hooked module.
  
  Loaded "SECHOST.DLL" at address 0x000007F9439B0000.  Successfully hooked module.
  
  DllMain(0x000007F9439B0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SECHOST.DLL" called.
  
  DllMain(0x000007F9439B0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SECHOST.DLL" returned 1 (0x1).
  
  DllMain(0x000007F944E40000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "ADVAPI32.DLL" called.
  
  DllMain(0x000007F944E40000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "ADVAPI32.DLL" returned 1 (0x1).
  
  LoadLibraryA("ADVAPI32.dll") returned 0x000007F944E40000.
  
  GetProcAddress(0x000007F944E40000 [ADVAPI32.DLL], "RegOpenKeyExW") called from "START8_64.DLL" at address 0x000007F93A1A1E59 and returned 0x000007F944E413D0.
  
  GetProcAddress(0x000007F944E40000 [ADVAPI32.DLL], "RegQueryValueExW") called from "START8_64.DLL" at address 0x000007F93A1A1E59 and returned 0x000007F944E413F0.
  
  GetProcAddress(0x000007F944E40000 [ADVAPI32.DLL], "RegCloseKey") called from "START8_64.DLL" at address 0x000007F93A1A1E59 and returned 0x000007F944E413B0.
  
  GetProcAddress(0x000007F943860000 [USER32.DLL], "GetWindowBand") called from "START8_64.DLL" at address 0x000007F93A1C0A91 and returned 0x000007F943863210.
  
  GetProcAddress(0x000007F943860000 [USER32.DLL], "SetWindowBand") called from "START8_64.DLL" at address 0x000007F93A1C0AC1 and returned 0x000007F943872BB0.
  
  DllMain(0x000007F93A130000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "START8_64.DLL" returned 1 (0x1).
  
  Loaded "DWMAPI.DLL" at address 0x000007F941120000.  Successfully hooked module.
  
  DllMain(0x000007F941120000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DWMAPI.DLL" called.
  
  DllMain(0x000007F941120000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "DWMAPI.DLL" returned 1 (0x1).
  
  Loaded "COMCTL32.DLL" at address 0x000007F940010000.  Successfully hooked module.
  
  DllMain(0x000007F940010000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "COMCTL32.DLL" called.
  
  DllMain(0x000007F940010000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "COMCTL32.DLL" returned 1 (0x1).
  
  Loaded "OLE32.DLL" at address 0x000007F945AB0000.  Successfully hooked module.
  
  DllMain(0x000007F945AB0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "OLE32.DLL" called.
  
  DllMain(0x000007F945AB0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "OLE32.DLL" returned 1 (0x1).
  
  Loaded "CRYPTBASE.DLL" at address 0x000007F9429A0000.  Successfully hooked module.
  
  Loaded "BCRYPTPRIMITIVES.DLL" at address 0x000007F942940000.  Successfully hooked module.
  
  DllMain(0x000007F942940000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "BCRYPTPRIMITIVES.DLL" called.
  
  DllMain(0x000007F942940000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "BCRYPTPRIMITIVES.DLL" returned 1 (0x1).
  
  DllMain(0x000007F9429A0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "CRYPTBASE.DLL" called.
  
  DllMain(0x000007F9429A0000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "CRYPTBASE.DLL" returned 1 (0x1).
  
  Loaded "SHCORE.DLL" at address 0x000007F941D20000.  Successfully hooked module.
  
  DllMain(0x000007F941D20000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SHCORE.DLL" called.
  
  DllMain(0x000007F941D20000, DLL_PROCESS_ATTACH, 0x0000000000000000) in "SHCORE.DLL" returned 1 (0x1).

• How can I get FFmpeg to locate installed libraries when —sysroot is pointing to another directory ?

  3 février 2013, par Xaero Degreaz

  I've been going at this, literally for days. I'm trying to build FFmpeg with libmp3lame for use in an Android application. The build script sets a --sysroot flag that points to the Android NDK directory necessary to build these libraries in a way that Android can use them.

  The problem comes when I add the flag to --enable-libmp3lame ; I get ERROR: libmp3lame >= 3.98.3 not found during the build start up. I know that LAME, and it's libraries are installed, because I can just run ./configure --enable-libmp3lame manually and the configuration launches without a hitch, and shows that libmp3lame is enabled for this build. However, building like this will simply not work for what I need it for, since I need the Android NDK to do some work.

  I've tracked the problem down to the fact that this build script is declaring the sysroot, and through some research, I've tried adding -Luser/include, -L/user/includeto the extra cflags, and ldflags (which I've read is the default search location for gcc). I've tried several other things as well, but I'm confident that someone out here can help with this specific problem. This entire build script is as follows :

  Extra info :

  • Build OS : Ubuntu 11.10
  • FFmpeg Ver : Latest from git
  • LAME Ver : 3.9.x
  • Android NDK : r7

  build.sh

  #!/bin/bash
  
  
  
  if [ "$NDK" = "" ]; then
  
      echo NDK variable not set, assuming ${HOME}/android-ndk
  
      export NDK=${HOME}/android-ndk
  
  fi
  
  
  
  SYSROOT=$NDK/platforms/android-3/arch-arm
  
  # Expand the prebuilt/* path into the correct one
  
  TOOLCHAIN=`echo $NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/*-x86`
  
  export PATH=$TOOLCHAIN/bin:$PATH
  
  
  
  rm -rf build/ffmpeg
  
  mkdir -p build/ffmpeg
  
  cd ffmpeg
  
  
  
  # Don't build any neon version for now
  
  for version in armv5te armv7a; do
  
  
  
          DEST=../build/ffmpeg
  
          FLAGS="--target-os=linux --cross-prefix=arm-linux-androideabi- --arch=arm"
  
          FLAGS="$FLAGS --sysroot=$SYSROOT"
  
          FLAGS="$FLAGS --soname-prefix=/data/data/net.smartnotes/lib/"
  
          FLAGS="$FLAGS --enable-shared --disable-symver"
  
          FLAGS="$FLAGS --enable-small --optimization-flags=-O2"
  
          FLAGS="$FLAGS --disable-everything --enable-protocol=file"
  
          FLAGS="$FLAGS --enable-libmp3lame --enable-encoder=nellymoser"
  
  
  
          case "$version" in
  
                  neon)
  
                      EXTRA_CFLAGS="-march=armv7-a -mfloat-abi=softfp -mfpu=neon"
  
                      EXTRA_LDFLAGS="-Wl,--fix-cortex-a8"
  
                      # Runtime choosing neon vs non-neon requires
  
                      # renamed files
  
                      ABI="armeabi-v7a"
  
                      ;;
  
                  armv7a)
  
                      # I have tried many things here.
  
                      EXTRA_CFLAGS="-march=armv7-a -mfloat-abi=softfp"
  
                      EXTRA_LDFLAGS=""
  
                      ABI="armeabi-v7a"
  
                      ;;
  
                  *)
  
                      # I have tried many things here.
  
                      EXTRA_CFLAGS="-Luser/include"
  
                      EXTRA_LDFLAGS=""
  
                      ABI="armeabi"
  
                      ;;
  
          esac
  
          DEST="$DEST/$ABI"
  
          FLAGS="$FLAGS --prefix=$DEST"
  
  
  
          mkdir -p $DEST
  
          echo $FLAGS --extra-cflags="$EXTRA_CFLAGS" --extra-ldflags="$EXTRA_LDFLAGS" > $DEST/info.txt
  
          ./configure $FLAGS --extra-cflags="$EXTRA_CFLAGS" --extra-ldflags="$EXTRA_LDFLAGS" | tee $DEST/configuration.txt
  
          [ $PIPESTATUS == 0 ] || exit 1
  
          make clean
  
          make -j4 || exit 1
  
          make install || exit 1
  
  
  
  done

• Size Discrepany in the ‘du’ Command

  22 juin 2012, par Multimedia Mike — General

  I had a problem today while using the common Unix command ’du’. As a refresher, ’du’ stands for disk usage and is a handy tool for understanding how much disk space is being occupied.

  I think ’du’ is probably doing the right thing. The problem might be that I’m getting strange (read : 1/2 the expected number) when running the tool against directories on vmhgfs, the VMware filesystem.

  Science Project
  On an Ubuntu Linux VMware session, my home directory is on the main file system, which is ext4. The directory /mnt/hgfs is reported by ’mount’ to be of type vmhgfs and is shared with the host machine.

  Create a directory in the home directory and generate a 10 MiB file :

  mkdir /home/melanson/dir
  dd if=/dev/urandom of=/home/melanson/dir/random-file bs=1048576 count=10
  

  Create a directory on the shared drive and copy the same file :

  mkdir /mnt/hgfs/vmshare/dir
  cp /home/melanson/dir/random-file /mnt/hgfs/vmshare/dir
  

  Run ’du’ on each directory using the -k and -h options :

  du -k /home/melanson/dir /mnt/hgfs/vmshare/dir
  10244   /home/melanson/dir
  5120    /mnt/hgfs/vmshare/dir
  du -h /home/melanson/dir /mnt/hgfs/vmshare/dir
  
  11M    /home/melanson/directory
  
  5.0M   /mnt/hgfs/vmshare/directory
  

  I noticed this discrepancy when I was trying to pack a set of files (akin to ’tar’-ing) living in a directory in the shared location. I was going mad trying to understand why the original directory was only 2 MB as reported by ’du’ but the final packed file was 4 MB.

  To be fair, the man page for ’du’ succinctly states that the tool’s purpose is merely to "estimate file space usage".