End user documentation on the driver:


In order to use ECW format with GDAL, you need to download the "ERDAS ECW/JP2 SDK" from the Hexagon Geospatial website. The 4.3 or newer read-only SDK should be available for free download after agreeing to licensing terms. In order to write ECW or JPEG2000 files via the ECW SDK it is necessary to purchase a write enabled version of the SDK from Hexagon Geospatial/ERDAS.

If the out of date libecwj 3.3 SDK can be found (e.g. or, it can also be used. It has significantly different licensing details. Some tickets and discussion below are related to the 3.3 SDK.

Building GDAL with ECW support on Unix

Assuming you've installed libecwj library under default location, procedure of adding ECW support to GDAL is simple and you only need to provide GDAL configure with path to the ECW SDK installation prefix:

$ cd /path/to/gdal
$ ./configure --with-ecw=/usr/local
$ make
# make install

You might find it necessary to define -DPOSIX and -DLINUX in CPPFLAGS in gdal/frmts/ecw/GNUmakefile as mentioned in #3344 if there are build problems.

After these steps, you should be able to see the ECW in the list of formats supported by your GDAL installation:

$ gdalinfo --formats|grep ECW
  ECW (rw): ERMapper Compressed Wavelets
  JP2ECW (rw+): ERMapper JPEG2000

Note: be sure to restart any services that may depend on GDAL ie. Apache to reload PHP MapScript

Binary ECW SDK and GCC >= 5.1

Use ECW SDK 5.4 if possible, together with GDAL >= r41789 (GDAL 2.3.0dev and GDAL 2.2.4), since this SDK is the first one to ship with a library with the new C++ ABI, which solves the below issues.

Since GCC 5.1, GCC uses by default a new C++ ABI for libstdc++, which is incompatible of the ECW SDK binaries prior to version 5.4. The workaround is to build GDAL with CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0" ./configure [options]

Note: this trick will not work if you link against other C++ libraries compiler with the new ABI (such as likbml, podofo, poppler, cryptopp, etc.. typically coming from your distrution). If you also need them, you'll have to recompile them from source with CXXFLAGS="-D_GLIBCXX_USE_CXX11_ABI=0"

Alternative tutorial for building on Linux

Building GDAL with ECW support on Windows

In the nmake.opt are the following instructions for building with read support with the 4.1 or newer readonly SDK.

# Uncomment the following and update to enable ECW read support with the 
# 4.1+ readonly SDK
#ECWDIR  = 	"c:/Program Files/ERDAS/ERDAS ECW JPEG2000 Read SDK"
#		-I$(ECWDIR)\include \
#		-I$(ECWDIR)\include/ecw/api -I$(ECWDIR)\include/ecw/jp2 \
#		-I$(ECWDIR)\include/ecw/ecw
#ECWLIB  = 	$(ECWDIR)\lib\vc90\win32\NCSEcw4_RO.lib \
#		$(ECWDIR)\lib\vc90\win32\NCSUtil4.lib \
#		$(ECWDIR)\lib\vc90\win32\NCScnet4.lib

Once built, you will need to copy the appropriate redistributable ECW DLLs into the path. For the above case with VC9 this might be accomplished something like:

  copy "C:\Program Files\ERDAS\ERDAS ECW JPEG2000 Read SDK\redistributable\vc90\win32\*.dll" C:\windows\system32

The above builds ECW support into the core GDAL DLL. In order to build the ECW and JP2ECW drivers as plugins uncomment the plugin line in the nmake.opt:

# To build ECW support as a plugin uncomment the following, and make sure
# to do "nmake /f plugin" in gdal/frmts/ecw and copy the two
# resulting DLLs to an appropriate place.

Then do the following in gdal/frmts/ecw (after the GDAL build) to create the plugins:

  nmake /f plugin

Then copy the resulting DLLs in that directory somewhere appropriate for GDAL plugins, like into a "gdalplugins" directory under the directory where the .exes live or into a directory pointed to by the GDAL_DRIVER_PATH configuration option (or environment variable).

Building libecwj 3.3 library on Unix

In order to use GDAL with ECW support under Linux, Solaris or Mac OS systems, you will need to build the libecwj library on your own, so it's required to download Image Compression SDK Source Code but not the binary distribution which is dedicated for Windows family systems. Current version is ECW SDK 3.3 and the source code package is named

The source code is equipped with configure and scripts. There is also an utility script called bootstrap that can be used to regenerate the configure and files, if you have installed required tools: autoconf, automake, m4, libtool.

In the former case, the procedure is simple:

$ cd /path/to/libecwj2-3.3
$ ./configure
$ make
# make install

where the last step should be run as superuser.

On SuSE 11, you need to pass a flag to the configure script so it uses c99 compatability.

$ cd /path/to/libecwj2-3.3
$ ./configure CFLAGS="-std=c99"
$ make
# make install

By default, the libecwj is installed using installation prefix pointing to /usr/local. You can change this location with --prefix option of configure script. Run ./configure --help for more details. If libecwj is compiled with --prefix (e.g. /usr/local/libecwj2-3.3) make install fails, because <prefix>/include is not created automatically. do a mkdir <prefix>/include (e.g. mkdir /usr/local/libecwj2-3.3/include) and run make install again.

On recent platforms (Fedora 16/17/18 and RHEL/CentOS 6) libecwj2 can crash you program when reading JPG2000-files. The error is in the XML-handling code that is bundled with libecwj2 and apparently this has become an issue with recent compilers. One workaround on the above mentioned platforms is to disable optimization when compiling libecwj2. This can be done by passing -O0 to configure:

$ ./configure CFLAGS="-O0" CXXFLAGS="-O0"

or to make:

$ make CFLAGS="-O0" CXXFLAGS="-O0"

Mac OS X notes

There are a few problems possible with libecwj2-3.3 on Mac OS X. For more details, refer to Ticket #2032 - Building with ECW support on Mac OS X

libecwj2-3.3 Patches

Building libecwj2-3.3 from source using recent compilers may require some improvements that can be found in the ticket #3162 - Fixes and patches for libecwj2.

A synthetic cumulative patch is available :

A problem with opening and closing many ECW files consuming large amounts of memory with libecwj2-3.3 may be resolved using the libecwj patch in

A patch to avoid overflow in Linux implementation of NCSPhysicalMemorySize() in libecwj2-3.3 is available in the ticket #3366. This work around big memory usage for computers with RAM > 2 GB.

A patch to fix crash when creating 16 bit JP2 (that occurs on 64bit platforms) is available in ticket #2593.

A patch to fix a crash in ECWInitialize() on recent platforms such as Fedora 17 using new GCC (4.7 ?) is available in ticket #4868 (i.e. std::length_error)

The patch should also help to work around std::bad_alloc issue on Linux GitHub

Open Tickets

No results

Last modified 3 years ago Last modified on Jul 17, 2020, 5:48:41 AM

Attachments (1)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.