https://issues.dlang.org/show_bug.cgi?id=24389

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ImportC
                 CC|                            |bugzilla@digitalmars.com

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
There isn't quite enough information there. If you could compile with cpp to capture the preprocessor output, we can pinpoint the exact line of failure.

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
Created attachment 1905
  --> https://issues.dlang.org/attachment.cgi?id=1905&action=edit
cpp output on .c file containing just #include <stdlib.h>

Okay. My experience with importC at this point is pretty much zero, so my experience with debugging it is zero, and I could be going about this the wrong way, but rather than try to fight the Phobos build to try to run specific build commands on stuff, I tried to reduce this to something simple that I can easily run build commands on, and given that the problem seems to be with stdlib.h, that should be straightforward. So, I created a file called a.c that was just

---
#include <stdlib.h>
---

and ran

   dmd a.c

which results in basically the same error as the Phobos build (except only
once):

---
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
---

I ran

   cpp a.c > b.c

and attached b.c here. However running

   dmd b.c

results in exactly the same error.

---
/usr/include/stdlib.h(352): Error: no type for declarator before `asm`
---

So, I don't know if that's helpful (since I would have thought that it would then show an error inside of b.c instead), but b.c does end up with

---
void __qsort_r_compat(void *, size_t, size_t, void *,
     int (*)(void *, const void *, const void *));
__asm__(".symver " "__qsort_r_compat" ", " "qsort_r" "@" "FBSD_1.0");
---

inside of it, which presumably is what you were looking for. Sticking just that in a file called c.c and running

   dmd c.c

results in

---
c.c(3): Error: no type for declarator before `asm
---

Hopefully that's generated from the same version of the macro that's used when zlib imports it in the Phobos build. I know that the dmd / Phobos build at least used to need gcc on FreeBSD for some stuff, but I don't know if it's currently required or used, and running cpp is definitely running clang. Either way, the error is the same.

So, hopefully that helps. If you need me to run something else, just ask. I don't have much experience trying to debug preprocessor issues (and what experience I do have is about a decade old at this point), though I guess that that's technically more experience than I have with importC.

--

https://issues.dlang.org/show_bug.cgi?id=24389

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Jonathan M Davis from comment #0)
> This is not an issue on the latest release of dmd - 2.070 - but it is an issue on master. It looks like with 2.070, we're still building zlib in
You mean 2.107 is ok? 2.108-dev is not?

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #4 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Jonathan M Davis from comment #2)
> ---
> void __qsort_r_compat(void *, size_t, size_t, void *,
>      int (*)(void *, const void *, const void *));
> __asm__(".symver " "__qsort_r_compat" ", " "qsort_r" "@" "FBSD_1.0");
> ---
I know what that is - as far as I'm aware as of writing, the ImportC parser does not support top-level asm declarations.

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Iain Buclaw from comment #4)
> (In reply to Jonathan M Davis from comment #2)
> > ---
> > void __qsort_r_compat(void *, size_t, size_t, void *,
> >      int (*)(void *, const void *, const void *));
> > __asm__(".symver " "__qsort_r_compat" ", " "qsort_r" "@" "FBSD_1.0");
> > ---
> I know what that is - as far as I'm aware as of writing, the ImportC parser does not support top-level asm declarations.
FYI https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Remarks

"""
Extended asm statements have to be inside a C function, so to write inline
assembly language at file scope (“top-level”), outside of C functions, you must
use basic asm.

You can use this technique to emit assembler directives, define assembly language macros that can be invoked elsewhere in the file, or write entire functions in assembly language.

Basic asm statements outside of functions may not use any qualifiers. """

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #6 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Support can be simply added to the parser, but I can't see DMD doing anything but ignore or error about it being there.

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #7 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ibuclaw created dlang/dmd pull request #16184 "partial bugzilla 24389 - importC: Parser support for top-level asm definitions" mentioning this issue:

- partial bugzilla 24389 - importC: Parser support for top-level asm definitions

https://github.com/dlang/dmd/pull/16184

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #8 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to Iain Buclaw from comment #3)
> (In reply to Jonathan M Davis from comment #0)
> > This is not an issue on the latest release of dmd - 2.070 - but it is an issue on master. It looks like with 2.070, we're still building zlib in
> You mean 2.107 is ok? 2.108-dev is not?

Yes, sorry. 2.107 is fine - for the Phobos build - whereas dmd master is not - presumably because dmd master is using importC for zlib, whereas 2.107 is not. However, 2.107 fails the simplified test case of just #including stdlib.h, so the importC issue is there regardless.

(In reply to Iain Buclaw from comment #6)
> Support can be simply added to the parser, but I can't see DMD doing anything but ignore or error about it being there.

I'm not sure what dmd should be doing here, but as far as the Phobos build goes, either dmd needs to be able to handle the __asm__ that FreeBSD 14 is using in stdlib.h and do the correct thing for zlib to work, or we're not going to be able to build zlib with importC on FreeBSD 14 (and thus can't build it with importC in general unless we're doing something different for FreeBSD).

It doesn't look like qsort_r is being used by anything in Phobos right now, so I don't think that the __asm__ has to actually work in this case in order to build zlib, though __asm__ like this could definitely pop up again in the future, since this is something that FreeBSD will sometimes do to change what's being linked (usually to fix compatibility issues). I don't know if other OSes do the same.

Either way, obviously, the closer that we can get to actually using the __asm__ properly, the better, and gdc and ldc are clearly in a much better position for that.

--

https://issues.dlang.org/show_bug.cgi?id=24389

--- Comment #9 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Jonathan M Davis from comment #8)
> It doesn't look like qsort_r is being used by anything in Phobos right now, so I don't think that the __asm__ has to actually work in this case in order to build zlib, though __asm__ like this could definitely pop up again in the future, since this is something that FreeBSD will sometimes do to change what's being linked (usually to fix compatibility issues). I don't know if other OSes do the same.
> 
> Either way, obviously, the closer that we can get to actually using the __asm__ properly, the better, and gdc and ldc are clearly in a much better position for that.
Alternatively, there's reverting the change that introduced using DMD to build zlib.

https://github.com/dlang/phobos/pull/8873

If not resorting back to using $CC for FreeBSD, maybe the zlib sources could be altered to filter out the bad code in the header?

https://reviews.freebsd.org/source/src/browse/main/include/stdlib.h$347

#undef __generic?

--