Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#60296 closed defect (fixed)

acpica: ld: library not found for -lMacportsLegacySupport

Reported by: ryandesign (Ryan Schmidt) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: Cc: kencu (Ken), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), cjones051073 (Chris Jones)
Port: acpica

Description

acpica fails to build:

ld: library not found for -lMacportsLegacySupport

Change History (10)

comment:1 Changed 7 months ago by ryandesign (Ryan Schmidt)

Cc: kencu added

Here's a better log with silent rules disabled.

The portfile says:

PortGroup           legacysupport 1.0
legacysupport.newest_darwin_requires_legacy 10

So why is the legacysupport portgroup adding -lMacportsLegacySupport on Darwin 15? Seems like a defect in the portgroup.

comment:2 Changed 7 months ago by ryandesign (Ryan Schmidt)

Cc: MarcusCalhoun-Lopez added

It might also be an adverse interaction with the makefile 1.0 portgroup which was just added to the port. I have no idea how that portgroup works.

comment:3 Changed 7 months ago by kencu (Ken)

the makefile PG appears to be trying to implement the idea we discussed of having base set up the environment for no-configure ports in a similar way to how we set it up for ports that use configure; this is a fine plan, and being able to switch it on or off is a good safety valve.

indeed both it and legacysupport are tweaking some of the same variables, and it seems they will need to be shown how to get along properly.

comment:4 Changed 7 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

I am still testing, but so far, two solutions that seem to work are:

  • switch the order of PortGroup legacysupport 1.0 and PortGroup makefile 1.0
  • use PortGroup legacysupport 1.1
Last edited 7 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) (previous) (diff)

comment:5 Changed 7 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

legacysupport 1.0 modifies variables for all systems at or below 10.11 before the rest of the Portfile is evaluated.
After the Portfile is evaluated, it tries to remove the modifications depending on the value of legacysupport.newest_darwin_requires_legacy.

makefile 1.0 modifies variables only after the Portfile is evaluated.

So if makefile 1.0 is before legacysupport 1.0,

  • variables are modified in legacysupport 1.0
  • legacysupport.newest_darwin_requires_legacy is set in Portfile
  • variables are used by makefile 1.0
  • variables are unmodified in legacysupport 1.0

If legacysupport 1.0 is before makefile 1.0,

  • variables are modified in legacysupport 1.0
  • legacysupport.newest_darwin_requires_legacy is set in Portfile
  • variables are unmodified in legacysupport 1.0
  • variables are used by makefile 1.0

legacysupport 1.1 is less obtrusive.
It never modifies variables until it is sure the system requires the changes.

comment:6 Changed 7 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Owner: set to MarcusCalhoun-Lopez
Resolution: fixed
Status: newclosed

In b87574317742a4cdc8b2dce4dbfc3fcd0c8f9fde/macports-ports (master):

acpica: order of legacysupport, makefile PGs matters

Fixes #60296

comment:7 in reply to:  5 Changed 7 months ago by kencu (Ken)

Replying to MarcusCalhoun-Lopez:

legacysupport 1.0 modifies variables for all systems at or below 10.11 before the rest of the Portfile is evaluated.
After the Portfile is evaluated, it tries to remove the modifications depending on the value of legacysupport.newest_darwin_requires_legacy.

legacysupport 1.1 is less obtrusive.
It never modifies variables until it is sure the system requires the changes.

Chris set it up this way, to make sure that the CFLAGS and LDFLAGS were set before the Portfile was first processed, so that ports that used those things would see proper values. And then removed them afterwards, after the portfile was processed, if newest_darwin_requires_legacy allowed.

It seemed more bulletproof to do it that way with 20,000 ports, lots of them not using the standard autotools or cmake systems, and lots of shenanigans going on in various ports where the legacysupport PG might have unpredictable effects.

It has worked OK until now, but there may well be a better way to accomplish the same reliable outcome. I am not sure how else you could reliably do it, but I am not up-to-speed on the parsing behaviour of portfiles with respect to the setting of env vars, so I won't opine.

Last edited 7 months ago by kencu (Ken) (previous) (diff)

comment:8 Changed 7 months ago by kencu (Ken)

Cc: cjones051073 added

comment:9 Changed 7 months ago by kencu (Ken)

Chris, adding you in so you can see what's up here.

comment:10 in reply to:  6 Changed 7 months ago by ryandesign (Ryan Schmidt)

Replying to MarcusCalhoun-Lopez:

acpica: order of legacysupport, makefile PGs matters

That's an ok workaround for now, but long-term it should be considered a bug in the portgroups if the order of inclusion of the portgroups is significant.

Note: See TracTickets for help on using tickets.