#41436 closed defect (fixed)
apache fails to build with clang
Reported by: | essandess (Steve Smith) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.1 |
Keywords: | Cc: | Ionic (Mihai Moldovan) | |
Port: | apache |
Description
:info:build /usr/bin/clang -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -bundle -undefined suppress -flat_namespace -o libproxy.so mod_proxy.lo proxy_cache.lo pr oxy_connect.lo proxy_ftp.lo proxy_http.lo proxy_util.lo :info:build duplicate symbol _ap_os_is_path_absolute in: :info:build mod_proxy.lo :info:build proxy_cache.lo :info:build duplicate symbol _ap_os_is_path_absolute in: :info:build mod_proxy.lo :info:build proxy_connect.lo :info:build duplicate symbol _ap_os_is_path_absolute in: :info:build mod_proxy.lo :info:build proxy_ftp.lo :info:build duplicate symbol _ap_os_is_path_absolute in: :info:build mod_proxy.lo :info:build proxy_http.lo :info:build duplicate symbol _ap_os_is_path_absolute in: :info:build mod_proxy.lo :info:build proxy_util.lo :info:build ld: 5 duplicate symbols for architecture x86_64 :info:build clang: error: linker command failed with exit code 1 (use -v to see invocation ) :info:build make[4]: *** [libproxy.so] Error 1
Attachments (1)
Change History (16)
Changed 11 years ago by essandess (Steve Smith)
comment:1 Changed 11 years ago by mf2k (Frank Schima)
Cc: | ryandesign@… openmaintainer@… removed |
---|---|
Owner: | changed from macports-tickets@… to ryandesign@… |
comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | mavericks added |
---|
Do you really need to build Apache version 1? Apache version 2, in the apache2 port, builds fine on Mavericks.
comment:3 Changed 11 years ago by essandess (Steve Smith)
Perhaps not -- I'm trying to install mod_perl and and apache is a dependency. I'll look into alternate options.
comment:4 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Try the mod_perl2 port instead, which uses apache2.
comment:5 Changed 11 years ago by jmroot (Joshua Root)
Looks like inlining gone awry, so maybe -std=gnu89 will help?
comment:6 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Keywords: | mavericks removed |
---|---|
Summary: | apache fails to build on Mavericks → apache fails to build |
Yeah, this doesn't look Mavericks related...
comment:7 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Summary: | apache fails to build → apache fails to build with clang |
---|
comment:8 Changed 11 years ago by mina.macports@…
For those of us stuck with apache1 legacy systems, I can confirm -std=gnu89 allows compilation to succeed
comment:9 Changed 10 years ago by Ionic (Mihai Moldovan)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:11 follow-up: 12 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ionic@… added |
---|
If the problem was a build failure, why would a revbump be necessary?
If you resolve a ticket, please assign the ticket to yourself or at least Cc yourself so that you're in the loop for any follow-up conversation.
comment:12 follow-up: 13 Changed 10 years ago by Ionic (Mihai Moldovan)
Replying to ryandesign@…:
If the problem was a build failure, why would a revbump be necessary?
Because the commit inserts patches which change the behavior generally (replacing -undefined suppress -flat_namespace
linker options with -undefined dynamic_lookup
), catches a clash with the libc's readline
function and adds -std=c89
to CFLAGS
.
Users having the port currently installed (on Tiger and below?) would have a diverging version of the port. But consistency is key!
If you resolve a ticket, please assign the ticket to yourself or at least Cc yourself so that you're in the loop for any follow-up conversation.
Sorry, I hope you don't mind me hijacking your ticket. It was stale for so long and I needed apache(1) to at least build successfully for another port update depending on apache(1).
comment:13 follow-up: 14 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ionic@…:
Because the commit inserts patches which change the behavior generally (replacing
-undefined suppress -flat_namespace
linker options with-undefined dynamic_lookup
),
Ah, ok. That's a good reason. I didn't look at the patch closely enough.
Users having the port currently installed (on Tiger and below?) would have a diverging version of the port. But consistency is key!
Yes. Note that Tiger is the earliest version on which MacPorts runs.
Sorry, I hope you don't mind me hijacking your ticket. It was stale for so long and I needed apache(1) to at least build successfully for another port update depending on apache(1).
Not at all, I appreciate you fixing it.
comment:14 follow-up: 15 Changed 10 years ago by Ionic (Mihai Moldovan)
Replying to ryandesign@…:
Not at all, I appreciate you fixing it.
Fixing*
.
*
I have not tested if it actually runs correctly. Or starts up. Or does anything. Chances are it works, but all bets are off.
comment:15 Changed 10 years ago by Ionic (Mihai Moldovan)
Replying to ionic@…:
Replying to ryandesign@…:
Not at all, I appreciate you fixing it.
Fixing
*
.
*
I have not tested if it actually runs correctly. Or starts up. Or does anything. Chances are it works, but all bets are off.
Ok... It starts up, can serve a simple, static "It works!" webpage and can be turned off again on 10.9. But that's as far as I'll go regarding testing apache(1).
It is not useful to Cc openmaintainer@….