0

lI am trying to use libpng in program, working on Windows Mobile 6.1.

To that end i created a c++ project from template "c++ SmartDevice Class library", and added to it appropriate c source files from libpng, using visual studio project provided there as a guide, and added the directory of libpng sources to source search directory.

However, when i try to compile, i get the following errors:

error C2054: expected '(' to follow 'PNG_DLL_EXPORT'    <path>\lib\lpng1512\png.h   991

In other words, first PNG_DLL_EXPORT causes an error, and after that it is an error on every following line of png.h.

What would be the cause? How that should be fixed? Is that a known issue?

Update: The exact macros used there is PNG_EXPORT. It is defined in pngconf.h as:

#define PNG_EXPORT(ordinal, type, name, args)\
   PNG_EXPORTA(ordinal, type, name, args, PNG_EMPTY)

Macros used are, consequently, defined as:

/* ANSI-C (C90) does not permit a macro to be invoked with an empty argument,
 * so make something non-empty to satisfy the requirement:
 */
#define PNG_EMPTY /*empty list*/

and

/* The ordinal value is only relevant when preprocessing png.h for symbol
* table entries, so we discard it here.  See the .dfn files in the
* scripts directory.
*/
#ifndef PNG_EXPORTA

#  define PNG_EXPORTA(ordinal, type, name, args, attributes)\
      PNG_FUNCTION(PNG_EXPORT_TYPE(type),(PNGAPI name),PNGARG(args), \
        extern attributes)
#endif

Down the rabbbit hole, there are:

/* In 1.5.2 the definition of PNG_FUNCTION has been changed to always treat
 * 'attributes' as a storage class - the attributes go at the start of the
 * function definition, and attributes are always appended regardless of the
 * compiler.  This considerably simplifies these macros but may cause problems
 * if any compilers both need function attributes and fail to handle them as
 * a storage class (this is unlikely.)
 */
#ifndef PNG_FUNCTION
#  define PNG_FUNCTION(type, name, args, attributes) attributes type name args
#endif

#ifndef PNG_EXPORT_TYPE
#  define PNG_EXPORT_TYPE(type) PNG_IMPEXP type
#endif

And further down:

#  if (defined(_MSC_VER) && _MSC_VER < 800) ||\
      (defined(__BORLANDC__) && __BORLANDC__ < 0x500)
    /* older Borland and MSC
     * compilers used '__export' and required this to be after
     * the type.
     */
#    ifndef PNG_EXPORT_TYPE
#      define PNG_EXPORT_TYPE(type) type PNG_IMPEXP
#    endif
#    define PNG_DLL_EXPORT __export
#  else /* newer compiler */
#    define PNG_DLL_EXPORT __declspec(dllexport)
#    ifndef PNG_DLL_IMPORT
#      define PNG_DLL_IMPORT __declspec(dllimport)
#    endif
#  endif /* compiler */

In other file, pngpriv.h, PNG_DLL_EXPORT finally IS used:

/* See pngconf.h for more details: the builder of the library may set this on
 * the command line to the right thing for the specific compilation system or it
 * may be automagically set above (at present we know of no system where it does
 * need to be set on the command line.)
 *
 * PNG_IMPEXP must be set here when building the library to prevent pngconf.h
 * setting it to the "import" setting for a DLL build.
 */
#ifndef PNG_IMPEXP
#  ifdef PNG_BUILD_DLL
#     define PNG_IMPEXP PNG_DLL_EXPORT
#  else
      /* Not building a DLL, or the DLL doesn't require specific export
       * definitions.
       */
#     define PNG_IMPEXP
#  endif
#endif

Update2: This issue is specific to compilation into dll. Compilation into lib doesn't cause the same compiler errors.

Srv19
  • 3,458
  • 6
  • 44
  • 75
  • Look for places where `PNG_DLL_EXPORT` is defined (I'm guessing it's a macro) and see what other defines are needed to give it a value. Perhaps your build environment lacks something that the PNG developers assume will be defined. – HonkyTonk Oct 03 '12 at 07:34
  • Definitions for PNG_DLL_EXPORT added to the body of question. – Srv19 Oct 03 '12 at 08:35
  • What is `libpng`? Is it (or the version you are using) compatible with Windows Mobile? –  Oct 04 '12 at 01:00
  • I will refer you to http://libpng.com/. As for compability - it is supposedly founded on basic native functions, that should be working there as well. – Srv19 Oct 04 '12 at 08:33

1 Answers1

0

Compilation into .lib completes successfully.

Reasons are unklear, though.

Srv19
  • 3,458
  • 6
  • 44
  • 75