From: xclaesse@gmail.com
To: LIU Hao <lh_mouse@126.com>, gcc@gcc.gnu.org
Subject: Re: Issue with dllexport/dllimport inline function
Date: Tue, 11 Oct 2022 10:26:08 -0400 [thread overview]
Message-ID: <0c24f08964acc66a402d94c1b6a389dee4efa163.camel@gmail.com> (raw)
In-Reply-To: <88c1e389-8d80-38bd-e1fa-e61d2653da8d@126.com>
Le mardi 11 octobre 2022 à 21:35 +0800, LIU Hao a écrit :
> 在 2022/10/11 21:28, LIU Hao via Gcc 写道:
> >
> > Did you have any declarations that had no `__gnu_inline__`? GNU
> > inline functions are supposed to be
> > emitted out of line, even when its address is taken.
> >
>
> This should be 'to be never emitted out of line'. Sorry for that.
I have one .c file, part of libglib-2.0-0.dll, that has that line:
```
extern int g_strcmp0 (const char *str1, const char *str2);
```
The header file has that:
```
GLIB_INLINE
int g_strcmp0 (const char *str1,
const char *str2)
{
if (!str1)
return -(str1 != str2);
if (!str2)
return str1 != str2;
return strcmp (str1, str2);
}
```
I now define GLIB_INLINE that way:
```
#if (defined(_WIN32) || defined(__CYGWIN__)) &&
!defined(GLIB_STATIC_COMPILATION)
# define _GLIB_EXPORT __declspec(dllexport)
# define _GLIB_IMPORT __declspec(dllimport)
#elif __GNUC__ >= 4
# define _GLIB_EXPORT __attribute__((visibility("default")))
# define _GLIB_IMPORT
#else
# define _GLIB_EXPORT
# define _GLIB_IMPORT
#endif
#ifdef GLIB_COMPILATION
# define _GLIB_API _GLIB_EXPORT
# define GLIB_INLINE __attribute__((__dllexport__))
__attribute__((__gnu_inline__)) extern inline
#else
# define _GLIB_API _GLIB_IMPORT
# if defined(__has_attribute) && __has_attribute(__gnu_inline__)
// https://gcc.gnu.org/pipermail/gcc/2022-October/239592.html
# define GLIB_INLINE __attribute__((__gnu_inline__)) extern inline
# else
# define GLIB_INLINE _GLIB_EXPORT extern inline
# endif
#endif
```
`GLIB_COMPILATION` is defined when compiling libglib-2.0-0.dll but not
when compiling other dlls or applications.
The linker issue actually happens when linking libglib-2.0-0.dll,
multiple definition happens for all .c files that actually uses
g_strcmp0:
```
/usr/bin/x86_64-w64-mingw32-ld: glib/libglib-2.0-
0.dll.p/deprecated_grel.c.obj: in function `g_strcmp0':
/home/xclaesse/programmation/glib/builddir/../glib/gtestutils.h:245:
multiple definition of `g_strcmp0'; glib/libglib-2.0-
0.dll.p/deprecated_gcache.c.obj:/home/xclaesse/programmation/glib/build
dir/../glib/gtestutils.h:245: first defined here
```
next prev parent reply other threads:[~2022-10-11 14:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-10 16:39 xclaesse
2022-10-11 5:00 ` LIU Hao
2022-10-11 13:10 ` xclaesse
2022-10-11 13:28 ` LIU Hao
2022-10-11 13:35 ` LIU Hao
2022-10-11 14:26 ` xclaesse [this message]
2022-10-11 17:42 ` LIU Hao
2022-10-11 18:37 ` xclaesse
2022-10-12 3:03 ` LIU Hao
2022-11-01 15:38 ` xclaesse
2022-11-01 16:06 ` LIU Hao
2022-11-01 18:11 ` xclaesse
2022-11-02 4:44 ` LIU Hao
-- strict thread matches above, loose matches on Subject: below --
2022-10-10 16:32 xclaesse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0c24f08964acc66a402d94c1b6a389dee4efa163.camel@gmail.com \
--to=xclaesse@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=lh_mouse@126.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).