Opened 16 years ago

Closed 15 years ago

Last modified 14 years ago

#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 16 years ago by afb@…

Or we could change +universal back to use the 10.5 SDK, cross-compiling is so much hassle...

comment:2 Changed 16 years ago by afb@…

Resolution: fixed
Status: newclosed

Fixed, r34317.

comment:3 in reply to:  2 Changed 15 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 15 years ago by illogic-al@…

Resolution: fixed
Status: closedreopened
Type: defectenhancement
Version: 1.7.01.6.0

comment:5 Changed 15 years ago by jmroot (Joshua Root)

I don't understand, aren't universal_target and universal_sysroot already independent variables?

comment:6 Changed 15 years ago by jmroot (Joshua Root)

Cc: illogic-al@… added; gui_dos@… removed

comment:7 in reply to:  5 ; Changed 15 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 Changed 15 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 in reply to:  7 ; Changed 15 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 in reply to:  8 Changed 15 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 in reply to:  9 ; Changed 15 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 in reply to:  11 ; Changed 15 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: reopenedclosed

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 in reply to:  12 Changed 15 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 15 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:15 Changed 15 years ago by illogic-al@…

This is marked as fixed, is it?

comment:16 Changed 15 years ago by afb@…

It was fixed earlier, then removed in r46451.

comment:17 Changed 15 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 in reply to:  17 Changed 15 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 15 years ago by afb@…

Resolution: fixed
Status: closedreopened

comment:20 Changed 15 years ago by afb@…

Owner: changed from afb@… to toby@…
Status: reopenednew

comment:21 Changed 15 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 15 years ago by tobypeterson

Probably the change to always set MACOSX_DEPLOYMENT_TARGET - this was not consistently done in 1.6

comment:23 Changed 15 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed

Yeah, MDT has the same effect. Please don't report bugs against 1.6...

comment:24 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.7.0

comment:25 Changed 14 years ago by jmroot (Joshua Root)

Component: portsbase
Note: See TracTickets for help on using tickets.