Opened 13 years ago

Last modified 13 years ago

#1338 closed defect (wontfix)

MinGW needs libproj.dll

Reported by: ari.jolma@… Owned by: warmerdam
Priority: highest Milestone:
Component: OGR_SF Version: unspecified
Severity: minor Keywords:
Cc: ari.jolma@…

Description

In ogrct.cpp, where the LIBNAME is defined, it should end up as libproj.dll, when compiled under MinGW. For example: 

#if defined(__MINGW32__)
#  define LIBNAME      "libproj.dll"

probably before WIN32 since that may also be defined in MinGW gcc.

Change History (7)

comment:1 Changed 13 years ago by warmerdam

Ari,

Does building GDAL with MINGW mean that only the MINGW version of PROJ
can be used with it?  I would have though that would not be the case, and
that it could easily use the regular win32 PROJ.DLL.   It seems to me that
assuming a mingw build of GDAL should look for a mingw build of PROJ is
at best a rough guess, only marginally better than the current guess to 
look for PROJ.DLL. 


comment:2 Changed 13 years ago by ari.jolma@…

No, it does not probably _require_ it. It may be better guess though. I had two libproj.dll's (the other from postgis) and two proj_fw.dll's but not proj.dll. Anyway, the current solution is not the best IMHO. Could it be a configuration parameter or could gdal search it using both names?

Ari

comment:3 Changed 13 years ago by warmerdam

Ari,

I think a patch to handle multiple names would be appropriate. 

I'd add that you can set the PROJSO configuration option to change what is
searched for, so it is relatively easy to work around at runtime if you
know what you are doing.  


comment:4 Changed 13 years ago by ari.jolma@…

RCS file: /cvs/maptools/cvsroot/gdal/ogr/ogrct.cpp,v
retrieving revision 1.36
diff -u -r1.36 ogrct.cpp
--- ogr/ogrct.cpp	23 Jun 2006 02:01:07 -0000	1.36
+++ ogr/ogrct.cpp	3 Nov 2006 05:32:10 -0000
@@ -180,16 +180,6 @@
 static char        *(*pfn_pj_get_def)(projPJ,int) = NULL;
 static void         (*pfn_pj_dalloc)(void *) = NULL;
 
-#if defined(WIN32) || defined(WIN32CE)
-#  define LIBNAME      "proj.dll"
-#elif defined(__CYGWIN__)
-#  define LIBNAME      "libproj.dll"
-#elif defined(__APPLE__)
-#  define LIBNAME      "libproj.dylib"
-#else
-#  define LIBNAME      "libproj.so"
-#endif
-
 /************************************************************************/
 /*                              OGRProj4CT                              */
 /************************************************************************/
@@ -241,7 +231,9 @@
 {
     CPLMutexHolderD( &hPROJMutex );
     static int  bTriedToLoad = FALSE;
-    const char *pszLibName = LIBNAME;
+    const char *pszLibName = NULL;
+    const char *libNames[] = {"libproj.so","proj.dll","libproj.dll","libproj.dylib"};
+    int nLibNames = 3, i = 0;
     
     if( bTriedToLoad )
         return( pfn_pj_init != NULL );
@@ -269,8 +261,14 @@
 #else
     CPLPushErrorHandler( CPLQuietErrorHandler );
 
-    pfn_pj_init = (projPJ (*)(int, char**)) CPLGetSymbol( pszLibName,
-                                                       "pj_init" );
+    if (pszLibName == NULL)
+      while (!pfn_pj_init && i < nLibNames) {
+	pszLibName = libNames[i];
+	pfn_pj_init = (projPJ (*)(int, char**)) CPLGetSymbol( pszLibName,
+							      "pj_init" );
+	i++;
+      }
+
     CPLPopErrorHandler();
     
     if( pfn_pj_init == NULL )
@@ -392,9 +390,8 @@
     if( !LoadProjLibrary() )
     {
         CPLError( CE_Failure, CPLE_NotSupported, 
-                  "Unable to load PROJ.4 library (%s), creation of\n"
-                  "OGRCoordinateTransformation failed.",
-                  LIBNAME );
+                  "Unable to load PROJ.4 library, creation of\n"
+                  "OGRCoordinateTransformation failed." );
         return NULL;
     }

comment:5 Changed 13 years ago by hobu

Ari,

What's the current status on this one?  Does it just need the patch applied?

Howard

comment:6 Changed 13 years ago by warmerdam

To be honest, I'm not really so thrilled with all this probing for 
shared libraries that make no sense on the platform. 

I also think that nLibNames is set wrong. 

comment:7 Changed 13 years ago by ari.jolma@…

(In reply to comment #6)
> To be honest, I'm not really so thrilled with all this probing for 
> shared libraries that make no sense on the platform. 
> 
> I also think that nLibNames is set wrong. 
> 

setting PROJSO works, so probing is not needed
Note: See TracTickets for help on using tickets.