Modify

Ticket #71 (closed defect: wontfix)

Opened 6 years ago

Last modified 6 years ago

libyaml does not build with MinGW

Reported by: clive.crous@… Owned by: xi
Priority: normal Component: libyaml
Severity: normal Keywords:
Cc:

Description

I'm unable to build libyaml under MinGW due to assumtions within the source code that "WIN32" means Visual Studio. I use gcc, even in windows.

Simple patch to yaml.h#260 fixes this =>

  • yaml.h

     
    2626 
    2727/** The public API declaration. */ 
    2828 
    29 #ifdef WIN32 
     29#if defined(WIN32) && !defined(__GNUC__) 
    3030#   if defined(YAML_DECLARE_STATIC) 
    3131#       define  YAML_DECLARE(type)  type 
    3232#   elif defined(YAML_DECLARE_EXPORT) 

Thanks, Clive

Attachments

Change History

comment:1 Changed 6 years ago by clive.crous@…

More than 2 months have past since I posted this :(

Anyone alive?

comment:2 Changed 6 years ago by xi

  • Status changed from new to closed
  • Resolution set to wontfix

I don't think your patch is correct. Most likely it does not build for you because you don't set a correct macro for your build: YAML_DECLARE_STATIC for building a static library or YAML_DECLARE_EXPORT for building DLL.

comment:3 Changed 6 years ago by clive.crous@…

  • Status changed from closed to reopened
  • Resolution wontfix deleted

Without the above patch the following happens:

C:\local\repositories\svn.pyyaml.org\libyaml\src\api.c: In function `yaml_get_version_string':
C:\local\repositories\svn.pyyaml.org\libyaml\src\api.c:24: internal compiler error: in rest_of_handle_final, at toplev.c:2067
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.

With the above patch, it compiles fine.

I've just retested this with the current trunk at revision:269

comment:4 Changed 6 years ago by xi

Looks like a bug in mingw?

comment:5 Changed 6 years ago by clive.crous@…

It should probably also be noted that if the following:

#ifdef WIN32

is removed completely inand one tries to compile under linux with GCC many many errors result due to declspec not being supported by GCC.

There is no such thing as declspec in GCC - that means linux as well as windows. So regardless of the mingw32 bug in handling something that it does not have, even if they resolve that bug the current code is still wrong as it should not be used when the compiler is GCC -- thus the above patch.

On a another note though, the above patch could probably be cleaned up by replacing

#ifdef WIN32

rather with

#ifdef _MSC_VER

Just as in the example from the GCC wiki page on visibility (  http://gcc.gnu.org/wiki/Visibility ):

#ifdef _MSC_VER
  #ifdef BUILDING_DLL
    #define DLLEXPORT __declspec(dllexport)
  #else
    #define DLLEXPORT __declspec(dllimport)
  #endif
  #define DLLLOCAL
#else
  #ifdef HAVE_GCCVISIBILITYPATCH
    #define DLLEXPORT __attribute__ ((visibility("default")))
    #define DLLLOCAL __attribute__ ((visibility("hidden")))
  #else
    #define DLLEXPORT
    #define DLLLOCAL
  #endif
#endif

extern "C" DLLEXPORT void function(int a);
class DLLEXPORT SomeClass
{
   int c;
   DLLLOCAL void privateMethod();  // Only for use within this DSO
public:
   Person(int _c) : c(_c) { }
   static void foo(int a);
};

comment:6 Changed 6 years ago by xi

  • Status changed from reopened to closed
  • Resolution set to wontfix

__declspec(dllexport) and __declspec(dllimport) are supported by GCC under Win32, see  http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html:

dllexport -- On Microsoft Windows targets and Symbian OS targets, the dllexport attribute causes the compiler to provide a global pointer to a pointer in a DLL, so that it can be referenced with the dllimport attribute. On Microsoft Windows targets, the pointer name is formed by combining _imp__ and the function or variable name.

You can use __declspec(dllexport) as a synonym for __attribute__ ((dllexport)) for compatibility with other compilers.

By dropping the dllexport/dllimport definitions, you just force the compiler to always build a static library instead of a DLL.

comment:7 Changed 6 years ago by clive.crous@…

lol, ok i'll just publish my fork, which builds under MinGW, which I need.

Since you're insisting on not fixing it, I'll keep my own repository copy which works.

comment:8 Changed 6 years ago by xi

If you are not yet convinced, just check an example at the end of the page you posted here ( http://gcc.gnu.org/wiki/Visibility). It starts with:

// Shared library support
#ifdef WIN32
  #define FXIMPORT __declspec(dllimport)
  #define FXEXPORT __declspec(dllexport)
  #define FXDLLLOCAL
  #define FXDLLPUBLIC
#else
...

comment:9 Changed 6 years ago by anonymous

I understand what you are saying, I see that.

However, seeing their examples does not fix libyaml, which cannot be compiled with MinGW.

comment:10 Changed 6 years ago by clive.crous@…

Sitting here re-reading my posts, I realize I'm being a bit of an arse-hat, sorry, it's late and I've not slept much of late. I'm going to stop commenting here and re-read when I've had some sleep and I'm in a less irritable mood :(

I did not mean to anger/flame/troll. Just frustrated that I can't compile libyaml with MinGW. I'll think about this some and come up with a solution rather than just being an arse in the comments of a bug report.

comment:11 Changed 6 years ago by xi

Clive, no offense taken. I realize that your problem is real, I just don't think that the fix is correct, especially since I've built libyaml with mingw before just fine. Admittedly it was a few years ago, so it may be broken now. Still if GCC segfaults, there something very wrong with the toolchain. Could you possibly post the versions of MinGW/MinSYS and GCC, as well as a complete dump of the build process?

Alternatively, you could just build libyaml with YAML_DECLARE_STATIC, it should have the same effect as adding && !defined(__GNUC__).

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.