Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#478 closed defect (invalid)

OSGeo4W 32bit: dumpbin failed on libintl-8.dll

Reported by: rashadkm Owned by: osgeo4w-dev@…
Priority: minor Component: Package
Version: Keywords:
Cc:

Description (last modified by jef)

dumpbin C:/OSGeo4W/bin/libintl-8.dll failed

I am getting the following error when building an NSIS package with OSGeo4W dependencies. This was caught by cmake when trying to get the dependencies.

CMake Error at C:/CMake-3.4.1/share/cmake-3.4/Modules/GetPrerequisites.cmake:798 (message):
  C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/dumpbin.exe
  failed: 1000
  Microsoft (R) COFF/PE Dumper Version 10.00.30319.01
  Copyright (C) Microsoft Corporation.  All rights reserved.
  Dump of file C:/OSGeo4W/bin/libintl-8.dll
  File Type: DLL
  LINK : fatal error LNK1000: Internal error during DumpSections
    Version 10.00.30319.01
    ExceptionCode            = C0000005
    ExceptionFlags           = 00000000
    ExceptionAddress         = 00147F10 (00120000) "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.exe"
    NumberParameters         = 00000002
    ExceptionInformation[ 0] = 00000000
    ExceptionInformation[ 1] = 00000004

  CONTEXT:
    Eax    = 40000040  Esp    = 003DE1E8
    Ebx    = 014281E0  Ebp    = 003DE210
    Ecx    = 00000004  Esi    = 00000004
    Edx    = 00124164  Edi    = 0000014C
    Eip    = 00147F10  EFlags = 00010246
    SegCs  = 00000023  SegDs  = 0000002B
    SegSs  = 0000002B  SegEs  = 0000002B
    SegFs  = 00000053  SegGs  = 0000002B
    Dr0    = 00000000  Dr3    = 00000000
    Dr1    = 00000000  Dr6    = 00000000
    Dr2    = 00000000  Dr7    = 00000000

Call Stack (most recent call first):
  C:/CMake-3.4.1/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 (get_prerequisites)
  C:/CMake-3.4.1/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 (get_prerequisites)
  C:/CMake-3.4.1/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 (get_prerequisites)
  C:/CMake-3.4.1/share/cmake-3.4/Modules/BundleUtilities.cmake:555 (get_prerequisites)
  C:/CMake-3.4.1/share/cmake-3.4/Modules/BundleUtilities.cmake:804 (get_bundle_keys)
  Code/Application/Mapla/cmake_install.cmake:119 (fixup_bundle)
  Code/Application/cmake_install.cmake:32 (include)
  Code/cmake_install.cmake:33 (include)
  cmake_install.cmake:39 (include)

Change History (8)

comment:1 Changed 6 years ago by jef

Description: modified (diff)
Priority: blockerminor

Maybe because libintl-8.dll is built with gcc?

comment:2 Changed 6 years ago by rashadkm

no idea.

BTW, why do osgeo4w mix msvc and mingw?

comment:3 in reply to:  2 Changed 6 years ago by martinl

Replying to rashadkm:

no idea.

BTW, why do osgeo4w mix msvc and mingw?

because not all packages are built with MSVC, some are depending on MinGW (for eg. GRASS)

comment:4 in reply to:  2 ; Changed 6 years ago by jef

Resolution: invalid
Status: newclosed

Replying to rashadkm:

BTW, why do osgeo4w mix msvc and mingw?

GRASS is not builable with MSVC - therefore it and some of it's (probably exclusive) dependencies are built with mingw.

BTW there's a creatensis.pl in QGIS that builds NSIS executables from OSGeo4W packages.

As this looks like a dumpbin/mingw incompatibility and not like a OSGeo4W issue I'm closing this ticket.

comment:5 in reply to:  4 ; Changed 6 years ago by rashadkm

Replying to jef:

Replying to rashadkm:

BTW, why do osgeo4w mix msvc and mingw?

GRASS is not builable with MSVC - therefore it and some of it's (probably exclusive) dependencies are built with mingw.

could we isolate grass in the install directory ? c:/osgeo4w/mingw/ c:/osgeo4w/msvc/

BTW there's a creatensis.pl in QGIS that builds NSIS executables from OSGeo4W packages.

I don't have problem with 64bit libraries in osgeo4w. Don't know it that helps.

As this looks like a dumpbin/mingw incompatibility and not like a OSGeo4W issue I'm closing this ticket.

If we look like that, other than the osgeo4w installer problem there is no other issues..

comment:6 in reply to:  5 ; Changed 6 years ago by jef

Replying to rashadkm:

could we isolate grass in the install directory ? c:/osgeo4w/mingw/ c:/osgeo4w/msvc/

Why?

As this looks like a dumpbin/mingw incompatibility and not like a OSGeo4W issue I'm closing this ticket.

If we look like that, other than the osgeo4w installer problem there is no other issues..

Which installer problem?

comment:7 in reply to:  6 ; Changed 6 years ago by rashadkm

Replying to jef:

Replying to rashadkm:

could we isolate grass in the install directory ? c:/osgeo4w/mingw/ c:/osgeo4w/msvc/

Why?

As this looks like a dumpbin/mingw incompatibility and not like a OSGeo4W issue I'm closing this ticket.

If we look like that, other than the osgeo4w installer problem there is no other issues..

Which installer problem?. I didn't say we had a problem in the installer. I mean other than the problems in the installer for osgeo4w,(if any in future). nothing can be considered an issue. Because all those dlls and packages are coming from other project.

Here the problem is with the way osgeo4w mix mingw and msvc dlls. So it should be considered.

comment:8 in reply to:  7 Changed 6 years ago by jef

Replying to rashadkm:

Here the problem is with the way osgeo4w mix mingw and msvc dlls. So it should be considered.

I don't see the problem with that - it works fine. If cmake/dumpbin cannot cope with working DLLs it should be fixed or worked around there. No need to review and possibly rework packages that work fine because of that.

Note: See TracTickets for help on using tickets.