can I remove '-Wl,-x' from ALL_LDFLAGS when leaving off the "Symbols" flag?

[premake]

can I remove '-Wl,-x' from ALL_LDFLAGS when leaving off the "Symbols" flag?

[starkos]

Did you set toolset "clang"?

[fzwoch]

This is the old issue with Apple's linker described here:
https://bitbucket.org/premake/premake-dev/issue/263/os-x-gcc-clang-and-the-infamous-wl-x

As mentioned there the only workaround at this time is to remove "-x" (this is exclusive to system == macosx, right?) altogether but instead issue a "strip -x" on the final binary.

I wanted to write a patch for it but couldn't figure out how to handle it in the code :/

For the record - I issued a bug report to Apple on this issue back in March 2015. It did not get any attention up to this date. So I guess it is safe to assume it is not getting fixed unless accidentally or upstream by LLVM if it is their bug at all.

[starkos]

Looking at the code, it appears we've already removed that flag for Clang though? We don't emit a strip -x yet, and we should (so let's keep this ticket open) but you shouldn't be getting a -Wl,-x if you've set the toolset to Clang. And if you are it would be good to know how that's happening so we can fix it!

[fzwoch]

Confirmed that 'toolset "clang"' is working fine - ignoring the fact it does not strip. I didn't come across the "toolset" option before. I assumed that "--cc=clang" on the command line would do this for me.

[starkos]

I assumed that "--cc=clang" on the command line would do this for me.

Yes, that should have been equivalent, you're right. Would be good to know what went wrong there? I haven't looked at that bit of code in quite a while.

[fzwoch]

I was not confident enough to actually create a pull request for this.. I think this might remedy the issue that --cc=clang was not set correctly picked up for the gmake target.

This was merely copied from the codelite module. Not sure if this is okay or should be fixed differently. This not being handled globally could mean every other module could easily fail here as well.

diff --git a/src/actions/make/make_cpp.lua b/src/actions/make/make_cpp.lua
index 9b746c8..573b199 100644
--- a/src/actions/make/make_cpp.lua
+++ b/src/actions/make/make_cpp.lua
@@ -81,9 +81,9 @@
                        -- identify the toolset used by this configurations (would be nicer if
                        -- this were computed and stored with the configuration up front)

-                       local toolset = premake.tools[cfg.toolset or "gcc"]
+                       local toolset = premake.tools[_OPTIONS.cc or cfg.toolset or "gcc"]
                        if not toolset then
-                               error("Invalid toolset '" + cfg.toolset + "'")
+                               error("Invalid toolset '" + (_OPTIONS.cc or cfg.toolset) + "'")
                        end

                        _x('ifeq ($(config),%s)', cfg.shortname)

[starkos]

It would be better if we could handle this in one place, and give the exporters a function they can call to get the correct value. Thinking off the top of my head:

---
-- Return the correct toolset adapter for the given configuration.
--
-- @param cfg
--    The configuration to be tested.
-- @param default
--    An optional toolset identifier (i.e. "gcc") to select if no value is
--    provided by the configuration.
-- @param language
--    An optional language identifier (i.e. "C++") to override the language
--    that has been set in the configuration.
-- @return
--    A toolset adapter or nil
---
function config.toolset(cfg, default, language)
   -- get the tool ID (i.e. "cc" or "cxx") for the given language
   -- TODO: write this function; maps "C"->"cc", "C++"->"cxx", etc.
   local tool = p.tools.identifyTool(language or cfg.language)

   -- get the toolset ID (i.e. "gcc" or "clang") 
   local toolset = _OPTIONS[tool] or cfg.toolset or default

   if toolset then
      return p.tools[toolset]
   end
end