Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: auto-disable the linker script where appropriate #60

Closed
PHHargrove opened this issue Jun 26, 2014 · 3 comments
Closed

RFE: auto-disable the linker script where appropriate #60

PHHargrove opened this issue Jun 26, 2014 · 3 comments

Comments

@PHHargrove
Copy link
Collaborator

Unless I am missing something we still expect whoever is building clang-upc to manually disable the UPC liker script on Darwin. The Solaris support that is nearing completion also requires one the manually disable the linker script.

Is there any reason not to make the following change (and the autoconf equivalent)?

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -202,6 +202,10 @@ endif()

 # UPC link script
 set(LIBUPC_ENABLE_LINK_SCRIPT TRUE CACHE STRING "enable UPC's use of a custom linker script; this will define the UPC shared section as a no load section on targets where this feature is supported (requires GNU LD)")
+if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR
+    ${CMAKE_SYSTEM_NAME} MATCHES "SunOS" )
+  set( LIBUPC_ENABLE_LINK_SCRIPT FALSE )
+}
 set(LIBUPC_LINK_SCRIPT ${LIBUPC_ENABLE_LINK_SCRIPT})

 # Check for backtrace on systems (freebsd,..) that need an extra library
@nenadv
Copy link

nenadv commented Jun 26, 2014

This makes sense. Note however, that Darwin Driver/Tools.cpp Link::ConstructJob does not try to place "-T" option on
the linker line and we are silently ignore the linker script option. I suspect the same is true for solaris. So
configuring it would not make a difference on that level (this cmake creates include/clang/Config/config.h that we use
for compiling Clang sources).

But, we also need the same change in runtime/libupc/CMakeLists.txt, in which case it is necessary. Making the code in
both files the same is appropriate. At some pint I have to compact this and use only one cmake file for all the duplicates.

Not to be picky, I don't like silent overrides if the user explicitly used the switch. We have few of those and I never
researched the issue.

On 6/25/14 5:18 PM, Paul H. Hargrove wrote:

Unless I am missing something we still expect whoever is building clang-upc to manually disable the UPC liker script
on Darwin. The Solaris support that is nearing completion also requires one the manually disable the linker script.

Is there any reason not to make the following change (and the autoconf equivalent)?

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -202,6 +202,10 @@ endif()

UPC link script

set(LIBUPC_ENABLE_LINK_SCRIPT TRUE CACHE STRING "enable UPC's use of a custom linker script; this will define the UPC shared section as a no load section on targets where this feature is supported (requires GNU LD)")
+if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR

  • ${CMAKE_SYSTEM_NAME} MATCHES "SunOS" )
  • set( LIBUPC_ENABLE_LINK_SCRIPT FALSE )
    +}
    set(LIBUPC_LINK_SCRIPT ${LIBUPC_ENABLE_LINK_SCRIPT})

Check for backtrace on systems (freebsd,..) that need an extra library


Reply to this email directly or view it on GitHub #60.

@PHHargrove
Copy link
Collaborator Author

Note that on Solaris the command to build the linker script fails because ld is not the gnu linker:

$ echo "int main(){}" | gcc -Xlinker --verbose -o /dev/null -xc -
ld: fatal: unrecognized option '--'

That creates a need to disable the link script on Solaris independent of passing (or not) the '-T' option at application link time.

We have few of those [...]

At first I read that as referring to "users" rather than to "silent overrides" or "switches". :-)

@nenadv
Copy link

nenadv commented Aug 21, 2014

Fixed by 038160c and clangupc/llvm-upc@6576fcd

@nenadv nenadv closed this as completed Aug 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants