Re: [PATCH v2 3/3] p1689r5: initial support
> "Ben" == Ben Boeckel via Gcc-patches writes: Ben> - `-fdeps-file=` specifies the path to the file to write the format to. I don't know how this output is intended to be used, but one mistake made with the other dependency-tracking options was that the output file isn't created atomically. As a consequence, Makefiles normally have to work around this to be robust. If that's a possible issue here then it would be best to handle it in this patch. Tom
Re: Issue with dllexport/dllimport inline function
Thanks a lot for your help. Sorry for late reply, but I gave your trick a try and it did not work: ``` /home/xclaesse/programmation/inline-example/builddir/../foo.h:7: multiple definition of `g_strcmp0'; libfoo.dll.p/foo.c.obj:/home/xclaesse/programmation/inline- example/builddir/../foo.h:7: first defined here ``` Updated the test case there: https://gitlab.gnome.org/xclaesse/inline-example Regards, Xavier Claessens. Le mercredi 12 octobre 2022 à 11:03 +0800, LIU Hao a écrit : > 在 2022/10/12 02:37, xclae...@gmail.com 写道: > > > > Build it with: > > meson setup builddir --cross-file cross_file_mingw64.txt > > ninja -C builddir/ > > > > And it fails with: > > That's because you compiled it as C. I used g++ to compile these, and > there was no such error. > > > For C, this inline issue is going to be much more messy due to lack > of COMDAT support about > `inline`. Your will need a dedicated macro for each translation unit. > A dirty solution looks like this: > > ``` > #ifndef INSIDE_FOO_C > __attribute__((__dllexport__)) inline > #endif > extern > int > g_strcmp0(const char*str1, const char*str2) > ... > ``` > > and in 'foo.c': > > ``` > #define INSIDE_FOO_C 1 > #include "foo.h" > > extern int g_strcmp0 (const char *str1, const char *str2); > ``` > > > Further reading: > > https://github.com/lhmouse/mcfgthread/wiki/Differences-between-GNU,-C99-and-C---%60inline%60 > > > -- > Best regards, > LIU Hao
Re: Issue with dllexport/dllimport inline function
在 2022-11-01 23:38, xclae...@gmail.com 写道:
Thanks a lot for your help.
Sorry for late reply, but I gave your trick a try and it did not work:
```
/home/xclaesse/programmation/inline-example/builddir/../foo.h:7:
multiple definition of `g_strcmp0';
libfoo.dll.p/foo.c.obj:/home/xclaesse/programmation/inline-
example/builddir/../foo.h:7: first defined here
```
Apologies for the typo. The `__dllexport__` in 'foo.h' should have been `__gnu_inline__`. If, for
some reason, it needs to be specified explicitly, you may do that in 'foo.c' instead.
'foo.h':
```
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2) {
...
```
'foo.c':
```
__attribute__((__dllexport__)) /* This is optional. */
extern int g_strcmp0 (const char *str1, const char *str2);
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2 3/3] p1689r5: initial support
On Tue, Nov 01, 2022 at 08:57:37 -0600, Tom Tromey wrote: > > "Ben" == Ben Boeckel via Gcc-patches writes: > > Ben> - `-fdeps-file=` specifies the path to the file to write the format to. > > I don't know how this output is intended to be used, but one mistake > made with the other dependency-tracking options was that the output file > isn't created atomically. As a consequence, Makefiles normally have to > work around this to be robust. If that's a possible issue here then it > would be best to handle it in this patch. I don't think there'll be any race here because it's the "output" of the rule as far as the build graph is concerned. It's also JSON, so anything reading it "early" will get a partial object and easily detect "something went wrong". And for clarity, the `-o` flag used in CMake with this is just a side effect of the `-E` mechanism used and is completely ignored in the CMake usage of this. --Ben
Re: Issue with dllexport/dllimport inline function
Oh, that seems to be working now.
Still got a small issue, glib compiles with -Werror=missing-
prototypes:
../foo.h:7:5: error: no previous prototype for ‘g_strcmp0’ [-
Werror=missing-prototypes]
I'm a bit lost with what the prototype would look like in this case.
I think `__attribute__((__dllexport__))` will be needed when building
with MSVC at least. Seems gcc, clang and msvc each wants a different
trick :/
Thanks,
Xavier Claessens.
Le mercredi 02 novembre 2022 à 00:06 +0800, LIU Hao a écrit :
> 在 2022-11-01 23:38, xclae...@gmail.com 写道:
> > Thanks a lot for your help.
> >
> > Sorry for late reply, but I gave your trick a try and it did not
> > work:
> > ```
> > /home/xclaesse/programmation/inline-example/builddir/../foo.h:7:
> > multiple definition of `g_strcmp0';
> > libfoo.dll.p/foo.c.obj:/home/xclaesse/programmation/inline-
> > example/builddir/../foo.h:7: first defined here
> > ```
> >
>
> Apologies for the typo. The `__dllexport__` in 'foo.h' should have
> been `__gnu_inline__`. If, for
> some reason, it needs to be specified explicitly, you may do that in
> 'foo.c' instead.
>
> 'foo.h':
> ```
> #ifndef INSIDE_FOO_C
> __attribute__((__gnu_inline__)) __inline__
> #endif
> extern
> int g_strcmp0(const char*str1, const char*str2) {
> ...
> ```
>
> 'foo.c':
> ```
> __attribute__((__dllexport__)) /* This is optional. */
> extern int g_strcmp0 (const char *str1, const char *str2);
> ```
>
>
>
>
> --
> Best regards,
> LIU Hao
>
Re: Fwd: Request easy bug fix
On 10/30/22 09:01, Baruch Burstein via Gcc wrote: On Tue, Feb 15, 2022 at 5:20 PM Jonathan Wakely wrote: On Tue, 15 Feb 2022 at 13:58, David Malcolm wrote: On Tue, 2022-02-15 at 12:55 +, Jonathan Wakely via Gcc wrote: On Tue, 15 Feb 2022 at 12:34, Baruch Burstein via Gcc < gcc@gcc.gnu.org> wrote: Hi, I hope it is not inappropriate to call attention to a specific bug. https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85487. Clang and the MSVC compiler both ignore any tokens after the pragma, so that seems good enough for GCC too: https://godbolt.org/z/norv947a5 I am sorry for posting this again, but to the best of my understanding of the thread at https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85487, the patch already exists (I am not sure where), and was not merged to GCC 12 only because I called attention to it too late in the dev cycle, so I am trying to get this in earlier for GCC 13. It is literally a "do-nothing" patch. Just a note, I won't object if someone wants to move this forward. jeff
Re: Issue with dllexport/dllimport inline function
在 2022/11/2 02:11, xclae...@gmail.com 写道:
Oh, that seems to be working now.
Still got a small issue, glib compiles with -Werror=missing-
prototypes:
../foo.h:7:5: error: no previous prototype for ‘g_strcmp0’ [-
Werror=missing-prototypes]
I'm a bit lost with what the prototype would look like in this case.
I think `__attribute__((__dllexport__))` will be needed when building
with MSVC at least. Seems gcc, clang and msvc each wants a different
trick :/
GCC accepts a plain declaration (no `extern`, no `__attribute` whatsoever), but Clang usually warns
about the inconsistency, and sometimes rejects it, so my suggestion is to copy the declaration from
its definition verbatim.
It might look unnecessarily verbose, however, should be safe in practice. I don't know much about
how MSVC handles such inconsistency, though.
```
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2);
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2) {
...
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
