LLVM Clang 10 no longer supports -Wl,--dll

[gh_origin]

I tried to compile a DLL. The compiler produced many object files but failed to link them because it said it doesn't understand the option --dll. I edit the options_clang.xml and remove -Wl,--dll from the value of LinkDynamic so it's basically like this:

<Command name="LinkDynamic"
                 value="$linker -shared -Wl,--output-def=$def_output -Wl,--out-implib=$static_output $libdirs $link_objects $link_resobjects -o $exe_output $link_options libs"/>

After that it could link the object files and produce a DLL.

[oBFusCATed]

There is a way to check the version of the compiler and make this conditional. After that post a patch and we might include it.

[gh_origin]

There is a way to check the version of the compiler and make this conditional. After that post a patch and we might include it.

How to write conditional in XML? The fastest hack I could think of is creating another XMLs for newer Clang, e.g: compiler_clang_old.xml, options_clang_old.xml (still have -Wl,--dll), compiler_clang_new.xml, options_clang_new.xml (no longer have -Wl,--dll). The checking for compiler version part just let the users do it by manually select their compiler (clang_old or clang_new).

[Miguel Gimenez]

You can use my patch for GCC in ticket 1006 (https://sourceforge.net/p/codeblocks/tickets/1006/) as a reference.

[gh_origin]

You can use my patch for GCC in ticket 1006 (https://sourceforge.net/p/codeblocks/tickets/1006/) as a reference.

I will try if I could do it after I cleared my confusion between the Dynamic Link Library project type and Shared Library project type. You could see my thread asked about that.

[gh_origin]

You can use my patch for GCC in ticket 1006 (https://sourceforge.net/p/codeblocks/tickets/1006/) as a reference.

Sorry, I still have no idea even when have read your code many times. I don't know how to adapt your code for this situation.

The situation between yours and mine seemed to completely different. "-std=" kind of options are to plug into compiler (not really needed). But the -Wl,--dll kind of options are part of the linker command itself. In no possible way I found it's able for me to do the same as with the former kind of options.

It seemed can't help with this problem.

[gh_origin]

The fastest hack I could think of is creating another XMLs for newer Clang, e.g: compiler_clang_old.xml, options_clang_old.xml (still have -Wl,--dll), compiler_clang_new.xml, options_clang_new.xml (no longer have -Wl,--dll). The checking for compiler version part just let the users do it by manually select their compiler (clang_old or clang_new).

I still think this is the optimal solution.

[Miguel Gimenez]

It does not look too difficult, here you have a possible patch (untested, I don't have Clang).

I have attached also the complete file (renamed from xml to txt) so you can paste it directly in the compilers directory.

[gh_origin]

It does not look too difficult, here you have a possible patch (untested, I don't have Clang).

I have attached also the complete file (renamed from xml to txt) so you can paste it directly in the compilers directory.

Perhaps it's because I'm stupid. You know, if I'm more intelligent, I'm now would not be a secondary school teacher. Maybe I'm teaching in college 

You are right when provided a ready working file, as I really don't know how to apply the patch. BTW, your XML has one minor problem. It has two "<?xml version="1.0"?>:" line so CodeBlocks doesn't consider it as valid so it said there is no options_clang.xml and just quit. Deleting the duplicated line and everything work as expected. Thank you for being patient with me.

[oBFusCATed]

Patches are applied with the patch utility or something similar.

[Miguel Gimenez]

I don't know why the line got duplicated, possibly it is BOM-related. I edited it with Notepad++, and only changed the options part.

[Miguel Gimenez]

I repeated the same steps, duplication does not happen  . This is the corrected patch.

[oBFusCATed]

@Miguel Gimenez This patch is not good. It doesn't handle future versions and requires constant changes with every new version of clang. You need to somehow make a test that does '<10' or something similar. But unfortunately Compiler::EvalXMLCondition doesn't seem to support such conditions.

[Miguel Gimenez]

It is just a proof of concept, if it were a finished patch I would have published it in a ticket.

[Miguel Gimenez]

Probably changing the regex from

Code

^(10|11|12)

to

Code

^([0-9][0-9]+)

or

Code

^([0-9]{2,})

is enough. I don't have Clang.

[oBFusCATed]

Regexes aren't good for this kind of checks.
We need something like https://cmake.org/cmake/help/latest/command/if.html?highlight=version_less
But I suppose it is fine if we drop older versions of clang.

[Miguel Gimenez]

EvalXMLCondition() can be easily expanded to evaluate this kind of conditions, adding p.e. "minimum" or "lessthan" verbs.

[oBFusCATed]

I know, I don't have the time to do it. If you're interested post patch, if not post a patch which drops the old version, I guess.

[killerbot]

I would drop support for old clang, by the way, most recent is clang11.

[oBFusCATed]

Yeah, this is easy, but I'm sure this feature would be useful for other places.

[Miguel Gimenez]

Ticket expanding EvalXMLCondition() published, https://sourceforge.net/p/codeblocks/tickets/1041/

[gh_origin]

I don't have Clang.

If you're on Linux, it's easy. If if you're on Windows, you can use my Clang:

https://app.box.com/s/8i0tovgsr354brkcwumus0nzfw1heigg

And sorry everyone, it's my mistake. The Clang version I shared through out the forum is not Clang 10, it's Clang 11 indeed. So I'm not sure whether it's Clang 11 or Clang 10 that dropped supports for -Wl,--dll.

You could get Clang 10 here:

https://app.box.com/s/9gs0idab4ui031043go90s1819uonkop

[gh_origin]

But I suppose it is fine if we drop older versions of clang.

No. The oldest version of Clang I have seen still being used is Clang 7 (on Linux). I also saw Clang 3.5 still floated around on some organizations. It's not unbelievable, though. Since in my place they only tried to conform to C++11. Newer language standards are not considered. So if old compilers have complete support for C++11, it's no reason to upgrade to new compilers, which most of time caused more problems than it worth.

[gh_origin]

I would drop support for old clang, by the way, most recent is clang11.

Most Linux distributions don't ship with latest Clang. The oldest Clang I saw still in use is Clang 7 (I don't remember which distributions, but it seemed to be some kind of LTS of Debian or Ubuntu).

BTW, why no one consider my solution: two sets of XMLs, one for old Clang, one for new Clang? I have posted about that many times on this thread but no one cares.

[stahta01]

Two files is twice the effort to maintain as one file.

Tim S.

[oBFusCATed]

BTW, why no one consider my solution: two sets of XMLs, one for old Clang, one for new Clang? I have posted about that many times on this thread but no one cares.

Because they easily get out of sync, they are harder to maintain and after all we need this version checking feature anyway. I'll if I can review the Miguel's patch.

[gh_origin]

BTW, why no one consider my solution: two sets of XMLs, one for old Clang, one for new Clang? I have posted about that many times on this thread but no one cares.

Because they easily get out of sync, they are harder to maintain and after all we need this version checking feature anyway. I'll if I can review the Miguel's patch.

I understand. Thanks.