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

[elf] understand -no-pie #11874

Merged
merged 1 commit into from
Jun 16, 2022
Merged

[elf] understand -no-pie #11874

merged 1 commit into from
Jun 16, 2022

Conversation

motiejus
Copy link
Contributor

This passes -Wl,-no-pie linker arg. Golang uses that. From the ld(1)
man page:

Create a position dependent executable. This is the default.

Not adding to the help text, because this is the default.

This passes -Wl,-no-pie linker arg. Golang uses that. From the `ld(1)`
man page:

   Create a position dependent executable.  This is the default.

Not adding to the help text, because this is the default.
motiejus added a commit to motiejus/zig that referenced this pull request Jun 16, 2022
Pass `-pagezero_size` to the MachO linker. This is the final
"unsupported linker arg" that I could chase that CGo uses. After this
and ziglang#11874 we may be able to fail on an "unsupported linker arg" instead
of emiting a warning.

Test case:

    zig=/code/zig/build/zig
    CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 CC="$zig cc -target x86_64-macos" CXX="$zig c++ -target x86_64-macos" go build -a -ldflags "-s -w" cgo.go

I compiled a trivial CGo program and executed it on an amd64 Darwin
host.

To be honest, I am not entirely sure what this is doing. This feels
right after reading what this argument does in LLVM sources, but I am by
no means qualified to make MachO pull requests. Will take feedback.
@andrewrk andrewrk merged commit d506275 into ziglang:master Jun 16, 2022
kubkon pushed a commit to motiejus/zig that referenced this pull request Jun 20, 2022
Pass `-pagezero_size` to the MachO linker. This is the final
"unsupported linker arg" that I could chase that CGo uses. After this
and ziglang#11874 we may be able to fail on an "unsupported linker arg" instead
of emiting a warning.

Test case:

    zig=/code/zig/build/zig
    CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 CC="$zig cc -target x86_64-macos" CXX="$zig c++ -target x86_64-macos" go build -a -ldflags "-s -w" cgo.go

I compiled a trivial CGo program and executed it on an amd64 Darwin
host.

To be honest, I am not entirely sure what this is doing. This feels
right after reading what this argument does in LLVM sources, but I am by
no means qualified to make MachO pull requests. Will take feedback.
@motiejus motiejus deleted the wl-no-pie branch June 22, 2022 09:09
motiejus added a commit to motiejus/zig that referenced this pull request Jun 22, 2022
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.

This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.

If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see ziglang#11679, ziglang#11875, ziglang#11874 for recent
examples.

With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.

Prerequisites: ziglang#11614 and ziglang#11863.
kubkon pushed a commit to motiejus/zig that referenced this pull request Jun 25, 2022
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.

This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.

If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see ziglang#11679, ziglang#11875, ziglang#11874 for recent
examples.

With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.

Prerequisites: ziglang#11614 and ziglang#11863.
andrewrk pushed a commit that referenced this pull request Jul 19, 2022
Pass `-pagezero_size` to the MachO linker. This is the final
"unsupported linker arg" that I could chase that CGo uses. After this
and #11874 we may be able to fail on an "unsupported linker arg" instead
of emiting a warning.

Test case:

    zig=/code/zig/build/zig
    CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 CC="$zig cc -target x86_64-macos" CXX="$zig c++ -target x86_64-macos" go build -a -ldflags "-s -w" cgo.go

I compiled a trivial CGo program and executed it on an amd64 Darwin
host.

To be honest, I am not entirely sure what this is doing. This feels
right after reading what this argument does in LLVM sources, but I am by
no means qualified to make MachO pull requests. Will take feedback.
wooster0 pushed a commit to wooster0/zig that referenced this pull request Jul 24, 2022
Pass `-pagezero_size` to the MachO linker. This is the final
"unsupported linker arg" that I could chase that CGo uses. After this
and ziglang#11874 we may be able to fail on an "unsupported linker arg" instead
of emiting a warning.

Test case:

    zig=/code/zig/build/zig
    CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 CC="$zig cc -target x86_64-macos" CXX="$zig c++ -target x86_64-macos" go build -a -ldflags "-s -w" cgo.go

I compiled a trivial CGo program and executed it on an amd64 Darwin
host.

To be honest, I am not entirely sure what this is doing. This feels
right after reading what this argument does in LLVM sources, but I am by
no means qualified to make MachO pull requests. Will take feedback.
andrewrk pushed a commit to motiejus/zig that referenced this pull request Dec 12, 2022
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.

This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.

If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see ziglang#11679, ziglang#11875, ziglang#11874 for recent
examples.

With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.

Prerequisites: ziglang#11614 and ziglang#11863.
andrewrk pushed a commit to motiejus/zig that referenced this pull request Jan 27, 2023
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.

This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.

If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see ziglang#11679, ziglang#11875, ziglang#11874 for recent
examples.

With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.

Prerequisites: ziglang#11614 and ziglang#11863.
motiejus added a commit to motiejus/zig that referenced this pull request Feb 9, 2023
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.

This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.

If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see ziglang#11679, ziglang#11875, ziglang#11874 for recent
examples.

With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.

Prerequisites: ziglang#11614 and ziglang#11863.
andrewrk pushed a commit that referenced this pull request Feb 17, 2023
Currently `zig cc`, when confronted with a linker argument it does
not understand, skips the flag and emits a warning.

This has been causing headaches for people that build third-party
software (including me). Zig seemingly builds and links the final
executable, only to segfault when running it.

If there are linker warnings when compiling software, the first thing we
have to do is add support for ones linker is complaining, and only then
go file issues. If zig "successfully" (i.e. status code = 0) compiles a
binary, there is instead a tendency to blaim "zig doing something
weird". (I am guilty of this.) In my experience, adding the unsupported
arguments has been quite easy; see #11679, #11875, #11874 for recent
examples.

With the current ones (+ prerequisites below) I was able to build all of
the CGo programs that I am encountering at $dayjob. CGo is a reasonable
example, because it is exercising the unusual linker args quite a bit.

Prerequisites: #11614 and #11863.
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

Successfully merging this pull request may close these issues.

None yet

2 participants