#14399 closed enhancement (fixed)
-mmacosx-version-min= should be appended to CFLAGS with universal variants on PPC
Reported by: | gui-dos (Guido Soranzio) | Owned by: | tobypeterson |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 1.7.0 |
Component: | base | Version: | 1.6.0 |
Keywords: | Cc: | illogic-al@…, jmroot (Joshua Root) | |
Port: |
Description
While compiling the first universal variants on Leopard 10.5.2 PPC using the latest MacPorts 1.7.0 from trunk, I found that several ports (zlib, jpeg) can't be linked correctly.
When "gcc -dynamiclib" is used, LDFLAGS isn't evaluated, but appending -mmacosx-version-min=10.4 to CFLAGS seems to solve the issue.
Instead of adding "configure.universal_cflags-append -mmacosx-version-min=10.4" to these ports, perhaps the proc configure_get_universal_cflags could be modified in order to append "-mmacosx-version-min=10.4" to the returned flags.
Change History (25)
comment:1 Changed 17 years ago by afb@…
comment:2 follow-up: 3 Changed 17 years ago by afb@…
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed, r34317.
comment:3 Changed 16 years ago by illogical1@…
Replying to afb@…:
Fixed, r34317.
But if someone wants to use the 10.4u sdk on 10.5 it breaks again so... reopen?
Is there a way in macports to test the sdk being used. I'm thinking of something along the lines of [sdkroot_isset 10.4u.sdk] and then adding "configure.universal_cflags-append -mmacosx-version-min=10.4" in that case.
comment:4 Changed 16 years ago by illogic-al@…
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Type: | defect → enhancement |
Version: | 1.7.0 → 1.6.0 |
comment:5 follow-up: 7 Changed 16 years ago by jmroot (Joshua Root)
I don't understand, aren't universal_target and universal_sysroot already independent variables?
comment:6 Changed 16 years ago by jmroot (Joshua Root)
Cc: | illogic-al@… added; gui_dos@… removed |
---|
comment:7 follow-up: 9 Changed 16 years ago by illogic-al@…
Replying to jmr@…:
I don't understand, aren't universal_target and universal_sysroot already independent variables?
Not that I know of. I don't see either of these in the portconfigure.tcl file (macports 1.6)
comment:8 follow-up: 10 Changed 16 years ago by mark.baas123@…
I have done attempts to build a universal gtk and the binaries were not compatible with tiger. I found out that macports defaults to build with 10.5sdk when it is installed, altough in the guide it says that you can define the universal_sysroot. After forcing to 10.4u.sdk, it still doesn't work, because of linking with -lcrt10.5.o. Then adding -mmacosx-version-min the problem is gone. So I think it is clear that this flag should be added to universal_cflags and universal_cxxflags.
comment:9 follow-up: 11 Changed 16 years ago by jmroot (Joshua Root)
Cc: | jmr@… added |
---|
Replying to illogic-al@…:
I don't see either of these in the portconfigure.tcl file (macports 1.6)
None of this stuff is available in 1.6. Check trunk: source:trunk/base/src/port1.0/portconfigure.tcl#L212
This looks fixed to me.
comment:10 Changed 16 years ago by illogic-al@…
Replying to mark.baas123@…:
I have done attempts to build a universal gtk and the binaries were not compatible with tiger. I found out that macports defaults to build with 10.5sdk when it is installed, altough in the guide it says that you can define the universal_sysroot. After forcing to 10.4u.sdk, it still doesn't work, because of linking with -lcrt10.5.o. Then adding -mmacosx-version-min the problem is gone. So I think it is clear that this flag should be added to universal_cflags and universal_cxxflags.
If universal_sysroot = 10.4u.sdk
comment:11 follow-up: 12 Changed 16 years ago by illogic-al@…
Replying to jmr@…:
Replying to illogic-al@…:
I don't see either of these in the portconfigure.tcl file (macports 1.6)
None of this stuff is available in 1.6. Check trunk: source:trunk/base/src/port1.0/portconfigure.tcl#L212
This looks fixed to me.
That's great, but it doesn't deal with the current macports release. What are users to do about this for 1.6 (granted, the number of people who would attempt this is presumably, quite small)?
comment:12 follow-up: 13 Changed 16 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Replying to illogic-al@…:
That's great, but it doesn't deal with the current macports release. What are users to do about this for 1.6 (granted, the number of people who would attempt this is presumably, quite small)?
I'm not sure what you're looking for here. Yes, 1.6 is broken. 1.7 will be fixed. If you really need this to work right now, you can install from svn, or you can edit your local portconfigure.tcl.
comment:13 Changed 16 years ago by illogic-al@…
Replying to jmr@…:
Replying to illogic-al@…:
That's great, but it doesn't deal with the current macports release. What are users to do about this for 1.6 (granted, the number of people who would attempt this is presumably, quite small)?
I'm not sure what you're looking for here. Yes, 1.6 is broken. 1.7 will be fixed. If you really need this to work right now, you can install from svn, or you can edit your local portconfigure.tcl.
I'm looking for a way to fix 1.6 now for users that doesn't require them to edit portconfigure.tcl themselves. Isn't there something like a 1.6 branch where changes can be checked in for just macports 1.6? I'm assuming that's the reason for port selfupdate.
comment:14 Changed 16 years ago by tobypeterson
Milestone: | MacPorts base bugs → MacPorts Future |
---|
Milestone MacPorts base bugs deleted
comment:17 follow-up: 18 Changed 16 years ago by illogic-al@…
Any chance we could add this back. I'm on an intel machine, and hit this bug multiple times w/ 1.6.0 when trying to compile 10.4 universal programs. I can try again with 1.7.0, but I don't see why there would be a change now (as 10.5 specifically needs this flag) despite what gcc -v is saying.
comment:18 Changed 16 years ago by illogic-al@…
Replying to illogic-al@…:
Any chance we could add this back. I'm on an intel machine, and hit this bug multiple times w/ 1.6.0 when trying to compile 10.4 universal programs. I can try again with 1.7.0, but I don't see why there would be a change now (as 10.5 specifically needs this flag) despite what gcc -v is saying.
I should point out that I'm compiling 10.4 universal binaries, on 10.5, which is why this flag is needed. The environment variable (setting the sdk) does not get respected in all places/source code.
comment:19 Changed 16 years ago by afb@…
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:20 Changed 16 years ago by afb@…
Owner: | changed from afb@… to toby@… |
---|---|
Status: | reopened → new |
comment:21 Changed 16 years ago by illogic-al@…
Updated to 1.7.1 yesterday and started recompiling everything. thus far things are problem free with all pre-kde4 ports. I've noticed differences in how some universal ports are building so changes may have been implemented to fix this without needing that patch which was removed (unless it made it into 1.7.1)
comment:22 Changed 16 years ago by tobypeterson
Probably the change to always set MACOSX_DEPLOYMENT_TARGET - this was not consistently done in 1.6
comment:23 Changed 16 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Yeah, MDT has the same effect. Please don't report bugs against 1.6...
comment:24 Changed 16 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future → MacPorts 1.7.0 |
---|
comment:25 Changed 15 years ago by jmroot (Joshua Root)
Component: | ports → base |
---|
Or we could change +universal back to use the 10.5 SDK, cross-compiling is so much hassle...