From: Danny S. <dan...@cl...> - 2003-09-19 20:16:09
|
The use of the "extern inline" GNU extension in mingw runtime is getting me into trouble with GCC's new -funit-at-a-time when compiling multiple files at once into a single output file, resulting in multiple definition errors when different input files include a header like math.h with extern inlined functions. This may be a bug in -funit-at-a-time that will eventually get fixed. But a similar problem will occur again when GCC enforces C99 semantics (inline if possible, but also emit an extern symbol) for the 'extern inline' syntax with -std=c99. I propose changing all to externs to static inline in headers for C, using a macro like #ifdef __cplusplus #define __CRT_INLINE inline #else #define __CRT_INLINE static __inline__ #endif Also, I wll probably need to add more guards that hide the inlines completely. The extern symbols for these inlines will still need to be maintained in libmingwex.a, since some libraries (built without optimization) may still be referenceing these as externs. Any comments. Danny |
From: Earnie B. <ea...@us...> - 2003-09-22 11:07:54
|
Danny Smith wrote: > The use of the "extern inline" GNU extension in mingw runtime is > getting me into trouble with GCC's new -funit-at-a-time when compiling > multiple files at once into a single output file, resulting in multiple > definition errors when different input files include a header like > math.h with extern inlined functions. This may be a bug > in -funit-at-a-time that will eventually get fixed. But a similar > problem will occur again when GCC enforces C99 semantics (inline if > possible, but also emit an extern symbol) for the 'extern inline' syntax > with -std=c99. > > I propose changing all to externs to static inline in headers for C, > using a macro like > > #ifdef __cplusplus > #define __CRT_INLINE inline > #else > #define __CRT_INLINE static __inline__ > #endif > > Also, I wll probably need to add more guards that hide the inlines > completely. > I'll agree. > The extern symbols for these inlines will still need to be maintained in > libmingwex.a, > since some libraries (built without optimization) may still be > referenceing these as externs. > Should we think about versionizing the file name? > Any comments. > Should we think about mingwex.dll? Earnie. -- http://www.mingw.org |
From: Danny S. <dan...@cl...> - 2003-09-23 23:02:48
|
----- Original Message ----- From: "Earnie Boyd > > I propose changing all to externs to static inline in headers for C, > > using a macro like > > > > #ifdef __cplusplus > > #define __CRT_INLINE inline > > #else > > #define __CRT_INLINE static __inline__ > > #endif > > > > Also, I wll probably need to add more guards that hide the inlines > > completely. > > > > I'll agree. I'll do this in two steps: 1) change all the extern inlines to use __CRT__INLINE, but still keep the meaning the same, ie: #define __CRT_INLINE extern __inline__ 2) Once I've played around a bit more and if it still seems like a good idea, I'll change the __CRT_INLINE define to static __inline__. > > > The extern symbols for these inlines will still need to be maintained in > > libmingwex.a, > > since some libraries (built without optimization) may still be > > referenceing these as externs. > > > > Should we think about versionizing the file name? Umm, no. libmingwex.a is now a system lib. Changing its name would require changing gcc specs > > > Any comments. > > > > Should we think about mingwex.dll? > I've thought about. Some of the functions written in asm may need a .def directive to define names as functions (rather than data) so they get exported correctly with export-all. Most already have these, but I may have missed a few. A def file is probably safer. I don't think addition of _CRTIMP to mingwex declarations is really a good idea yet, I'm thinking about potential problems with functions that are also inlined. Danny > Earnie. > -- > http://www.mingw.org > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Luke D. <cod...@ho...> - 2003-09-24 01:26:52
|
----- Original Message ----- From: "Danny Smith" <dan...@cl...> To: <min...@li...> Sent: Wednesday, September 24, 2003 7:01 AM Subject: Re: [MinGW-dvlpr] extern inline problems > > > > Should we think about mingwex.dll? > > > > I've thought about. Some of the functions written in asm may need a > .def > directive to define names as functions (rather than data) so they get > exported correctly > with export-all. Most already have these, but I may have missed a few. > A def file is probably safer. > > I don't think addition of _CRTIMP to mingwex declarations is really a > good idea yet, > I'm thinking about potential problems with functions that are also > inlined. > > Danny > > > Earnie. > > -- What do you think are the advantages of making the library a DLL? I can only imagine slightly smaller executables, which I don't think outweighs the problems of multiple versions of the DLL on the same system. Luke |
From: Danny S. <dan...@cl...> - 2003-09-24 02:05:26
|
----- Original Message ----- From: "Luke Dunstan" > From: "Danny Smith" > > > > > > > Should we think about mingwex.dll? > > > > > > > I've thought about. Some of the functions written in asm may need a > > .def > > directive to define names as functions (rather than data) so they get > > exported correctly > > with export-all. Most already have these, but I may have missed a few. > > A def file is probably safer. > > > > I don't think addition of _CRTIMP to mingwex declarations is really a > > good idea yet, > > I'm thinking about potential problems with functions that are also > > inlined. > > > > Danny > > > > > Earnie. > > > -- > > What do you think are the advantages of making the library a DLL? I can only > imagine slightly smaller executables, which I don't think outweighs the > problems of multiple versions of the DLL on the same system. > Like I said I thought about it. That's all. I don't believe it's worth it yet. I have complex functions waiting to be added and one day I might have time to clean up the mbrtowc functions, so I still think of libmingwex as a work in progress. My opinion is that dll worries can wait. Danny > Luke > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |