use -fvisibility=hidden with c objects can not compile

[patrickkh7788]

For example I build sqlite object file with D source into so (-shared -fvisibility=hidden), result with undefined reference to `abort' and all sqlite symbols. remove -fvisibility=hidden it can build and pass test.

I try add -L-lc, still report missing symbols. (test on android termux arm32).

please provide example how it work with c static lib or object files.

[kinke]

please provide example

Sure, we have nothing better to do with our spare time. I don't recall a single piece of D source you provided in any of your issues so far, so maybe it should be you providing some code. I don't mean to be too rude, but this kind of issues (hey, I'm using some cmdline switch I don't really understand, and it's not working) aren't helpful (and I'm quite sure the problem isn't LDC).

[kinke]

In case you're fwd declaring C functions to be linked in from other shared libs (sqlite etc.) yourself, i.e., not importing them from a 3rd party module, and only using those functions inside that module (compiled with the new switch), you might currently need to fwd declare them as export. But that's just a guess after quickly looking up the PR again.

[kinke]

Hmm, seems like isImportedSymbol() is not what I was expecting. We should probably declare all functions with public visibility and only optionally hide them when defining them; this is different to Windows, where the extra export for the dllimport attribute of symbols provided by other DLLs is to be expected (extra symbol name prefix etc.).

[kinke]

=> #2923

[patrickkh7788]

sorry, here is the example I test not work.

ldc2 -c hidden1.d -betterC -fvisibility=hidden

module hidden1;
extern(C) int printf(const(char)*, ...);
void test(){
        printf("%d", 123);
}

ldc2 hidden.d -betterC -fvisibility=hidden hidden1.o

import hidden1;

extern(C) void main(){
        test();
}

This also not work: ldc2 hidden.d -betterC -fvisibility=hidden hidden1.d

I understand the link shared c lib should be use with export, but I think the inner sub module should not ask for export.

If we need to export every cross module ref to made it compile, then it is not useful in most case. or people need force to merge every module into one.

And please consider to do we need support use Makefile to compile each module into object and link them together late. and maybe explain if we support this or not in the documentation or changelog.

[kinke]

I figured the issue; the feature is really unusable as it is in beta2, but fixed in the PR. So thx, your report did help, but it's just considerably more work if I have to study the code to form a hypothesis & come up with a testcase myself.

[patrickkh7788]

Understood, I will try provide test case to help reduce the work in future issues.