ImportC linking issue

[confuzzled]

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!!!