Skip to content

Clang Does Not Supply Correct Linker Flags Under Slackware #10103

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

Closed
llvmbot opened this issue Apr 15, 2011 · 2 comments
Closed

Clang Does Not Supply Correct Linker Flags Under Slackware #10103

llvmbot opened this issue Apr 15, 2011 · 2 comments
Labels
bugzilla Issues migrated from bugzilla clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl'

Comments

@llvmbot
Copy link
Member

llvmbot commented Apr 15, 2011

Bugzilla Link 9731
Resolution FIXED
Resolved on Aug 14, 2011 02:58
Version trunk
OS Linux
Attachments Minimal solution diff
Reporter LLVM Bugzilla Contributor
CC @tkremenek

Extended Description

To Reproduce:
Attempt to link together files with most recent clang version on Slackware.

Results:
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find crtbegin.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Fix:
ToolChains.cpp must have the path added for the Slackware gcc directory.
See attached diff for minimal fix for C linking under Slackware.

Note:
Based upon how the function for identifying the GccTripple, it seems as though it would be more logical and portable to find the /??/gcc/ folder and assume that the folder nested inside of it is the GccTripple.
This may be invalid in some special cases, but it appears to be much more general than the current approach.

@tkremenek
Copy link
Contributor

I committed this patch in r129704.

I agree that searching for /??/gcc may be more flexible, although there are advantages to explicitly enumerating (some cases) so that the behavior is well-defined. I think the design of this functionality is worth bringing up on cfe-dev. I personally don't have a strong opinion.

@llvmbot
Copy link
Member Author

llvmbot commented Aug 14, 2011

Path fix for Slackware64
Slackware64 has same issue, but needs the 64bit path added (for using 64bit triple). Attached is patch adding this path, in same manner as original patch above.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
weliveindetail pushed a commit to weliveindetail/llvm-project that referenced this issue Feb 26, 2025
…e interop mode (llvm#10060) (llvm#10103)

For a __null_terminated pointer 'p', only a __null_terminated pointer,
a string literal or a call to `std::string::c_str/data` can be assigned to
(/passed to/used to initialize, etc.) 'p'.  Otherwise, an error will be emitted.
The implementation reuses Bounds Safety's diagnostics.

(rdar://138798346)
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl'
Projects
None yet
Development

No branches or pull requests

2 participants