Re: ImportC linking issue
On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: It seems that every time I resolve one of these undefined symbols issues, the compiler finds more. So I keep copying lib files from locations that are a path, to my working directory and linking them to my script. Is that the norm? Do I need to configure DMD somehow to recognize C libraries that are already in the path? The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. These two things need to be true: * any link-time dependencies (object files, static libraries, shared libraries (link libraries on Windows)) need to be passed to the linker * the linker needs to know where to find libraries not on the default search path The only thing the compiler passes along automatically are the object files generated from the source and the standard library it's building a binary. Anything else (including separately compiled object files), you have to pass along explicitly. If you aren't explicitly passing any libraries along, then the linker won't know anything about them. The compiler doesn't know about them either, so can't pass them along for you. If you are passing them along but they aren't on the default lib path, then the linker won't be able to find them. Based on your description, it sounds like the last case is true for you. If so, if your libraries are in a common location, you can pass that path to the linker through dmd via `-L`. E.g., on Linux, `-L-L/path/to/libs`. On Windows, it depends on which linker you're using. For the Microsoft linker, it's `-L/LIBPATH path\\to\\libs`. You can also just pass the full path to each library.
Re: ImportC linking issue
On Saturday, 12 November 2022 at 08:43:13 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. Mike, first of all, thanks for the in depth response. That all makes sense. The issue I'm having is this: having made sure the two dependencies are available and building the libxlsxio_reader.a from the source without errors, why would I need to hunt down all the dependencies from that library to include them in my program? I figured that importing the header and passing libxlsxio_read.a on the command line would be enough? Why would I have to search for libcrypto, libminizip, libexpat, and more that I haven't even figured out what library they are? I thought those dependencies would already be linked into libxlsxio_read.a which is a statically linked library. I guess my noob is showing a lot. Again, thanks for your assistance. confuzzled!!!
Re: ImportC linking issue
On Saturday, 12 November 2022 at 10:02:12 UTC, confuzzled wrote: On Saturday, 12 November 2022 at 08:43:13 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. Mike, first of all, thanks for the in depth response. That all makes sense. The issue I'm having is this: having made sure the two dependencies are available and building the libxlsxio_reader.a from the source without errors, why would I need to hunt down all the dependencies from that library to include them in my program? I figured that importing the header and passing libxlsxio_read.a on the command line would be enough? Why would I have to search for libcrypto, libminizip, libexpat, and more that I haven't even figured out what library they are? I thought those dependencies would already be linked into libxlsxio_read.a which is a statically linked library. Static library dependencies are resolved at link time. Anything they need to link with, your binary must link with. It's shared libraries that have their static dependencies all baked in.
Re: ImportC linking issue
On Saturday, 12 November 2022 at 11:44:06 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 10:02:12 UTC, confuzzled wrote: On Saturday, 12 November 2022 at 08:43:13 UTC, Mike Parker wrote: On Saturday, 12 November 2022 at 02:45:52 UTC, confuzzled wrote: The linker doesn't care if the libraries are C or D, and the compiler is only involved in that you can pass flags to the linker via the compiler command line. Mike, first of all, thanks for the in depth response. That all makes sense. The issue I'm having is this: having made sure the two dependencies are available and building the libxlsxio_reader.a from the source without errors, why would I need to hunt down all the dependencies from that library to include them in my program? I figured that importing the header and passing libxlsxio_read.a on the command line would be enough? Why would I have to search for libcrypto, libminizip, libexpat, and more that I haven't even figured out what library they are? I thought those dependencies would already be linked into libxlsxio_read.a which is a statically linked library. Static library dependencies are resolved at link time. Anything they need to link with, your binary must link with. It's shared libraries that have their static dependencies all baked in. Right, so I figured that the dependencies for for libxlsxio_read would be resolved when it was being compiled/linked. Therefore, when I used it later, I would just need to import its and include it on the command line. I didn't realize I would have to hunt down those libraries again and link them to my program, especially since I don't know what most of them are. I didn't have to provide them to the linker when I compiled libxlsxio_read. Anyway, thanks for the explanation. I was definitely thinking and going about this all wrong. Appreciate the clarification. confuzzled!!!
Re: ImportC linking issue
On Saturday, 12 November 2022 at 12:48:40 UTC, confuzzled wrote: Right, so I figured that the dependencies for for libxlsxio_read would be resolved when it was being compiled/linked. Therefore, when I used it later, I would just need to import its and include it on the command line. I didn't **import its header and provide the library on the command line***
Using glibc headers with ImportC
I'm trying to get D to use my system's libc. First of all, is such a thing possible with importc? Walter Bright's slides on importc say it should be "as easy as import stdio;", but it doesn't seem to be the case yet. In the specification page I see that importc looks for .c and .i files, not .h . Is it possible to do what I'm trying to do? And if so, how? By the way, I know I can "import core.stdc.stdio;" and I'm sure it's a better option. I'm not trying to do anything important here, it's just to figure out how it works.
Re: Using glibc headers with ImportC
This is supposed to work, right?
```
import stdio;
void main() {
printf("Hello, World!\n");
}
```
In my case, DMD complains of not being able to read `stdio.d`.
What am I doing wrong? I'm not using any compiler switch.
Sorted Array (Container) Type
Have anybody created a wrapper container ```d struct Sorted(ArrayLike, alias lessThanPred) ``` that wraps an array-like type `ArrayLike` so that it's always sorted according to the binary predicate `lessThanPred`?
Re: Using glibc headers with ImportC
On Saturday, 12 November 2022 at 13:46:27 UTC, qua wrote: This is supposed to work, right? No, it isn't. And it probably never will. importC looks for a .c file in the current directory. It is that .c file's responsibility to #include whatever .h files you want.
Re: Using glibc headers with ImportC
On Saturday, 12 November 2022 at 14:14:06 UTC, Adam D Ruppe wrote:
No, it isn't. And it probably never will.
importC looks for a .c file in the current directory. It is
that .c file's responsibility to #include whatever .h files you
want.
Okay, thanks, got it. However, I'm still having issues to get it
to compile.
I have tried the example in the importc page and it compiles (and
works) well. However, I can't get any example with `#include` to
compile, including the simple hello.c in the importc page:
```
#include
int main()
{
printf("hello world\n");
return 0;
}
```
I get the following errors:
```
hello.c(1): Error: identifier or `(` expected
hello.c(5): Error: identifier or `(` expected
hello.c(6): Error: identifier or `(` expected
```
Do I have to do anything else? I've read that importc doesn't
have a preprocessor and I assume it is related to that, however
"ImportC can automatically run the C preprocessor associated with
the Associated C Compiler". Is it necessary to enable or specify
it in some way?
Thanks for your help.
Re: Using glibc headers with ImportC
On Saturday, 12 November 2022 at 14:39:14 UTC, qua wrote: Do I have to do anything else? I've read that importc doesn't have a preprocessor and I assume it is related to that, however "ImportC can automatically run the C preprocessor associated with the Associated C Compiler". I still don't think that's been released yet, so if you aren't on the git master or at least the latest beta build it isn't going to work. Which dmd version are you running?
Re: Using glibc headers with ImportC
On Saturday, 12 November 2022 at 14:57:23 UTC, Adam D Ruppe wrote: I still don't think that's been released yet, so if you aren't on the git master or at least the latest beta build it isn't going to work. Which dmd version are you running? I was running 2.098, I have just installed 2.100.2, which does say that use of #include is not supported. I have tried too to preprocess hello.c with `gcc -E`, but dmd is also unable to compile it preprocessed (with errors such as /usr/include/stdio.h(246): Error: found `__filename` when expecting `,` ). Is there any reasonably simple way to compile files such as this hello.c, or is it not ready yet? I'm not an experienced programmer, so I mostly want to know if I'm doing something wrong or if there's an alternative that doesn't require manual translations from C to D.
Re: Using glibc headers with ImportC
On Saturday, 12 November 2022 at 15:08:22 UTC, qua wrote: On Saturday, 12 November 2022 at 14:57:23 UTC, Adam D Ruppe wrote: I still don't think that's been released yet, so if you aren't on the git master or at least the latest beta build it isn't going to work. Which dmd version are you running? I was running 2.098, I have just installed 2.100.2, which does say that use of #include is not supported. I have tried too to preprocess hello.c with `gcc -E`, but dmd is also unable to compile it preprocessed (with errors such as /usr/include/stdio.h(246): Error: found `__filename` when expecting `,` ). Is there any reasonably simple way to compile files such as this hello.c, or is it not ready yet? I'm not an experienced programmer, so I mostly want to know if I'm doing something wrong or if there's an alternative that doesn't require manual translations from C to D. You're going to need to use the nightly from here: https://github.com/dlang/dmd/releases/tag/nightly While a lot of progress has been made, it's definitely not finished, so you may still encounter errors here and there.
Re: Using glibc headers with ImportC
On Saturday, 12 November 2022 at 15:13:36 UTC, bachmeier wrote: You're going to need to use the nightly from here: https://github.com/dlang/dmd/releases/tag/nightly While a lot of progress has been made, it's definitely not finished, so you may still encounter errors here and there. Thanks! Just installed the nightly version and it works as expected.
