Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#12041 closed defect (invalid)

configure script of "macports" should not link against "/usr/local/"

Reported by: cilly@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.4.40
Keywords: Cc: cilly@…,markd@…
Port:

Description

Wile upgrading macports it links itself against anything installed in /usr/local, once a software package in /usr/local is removed, macports does not work work anymore since the port binary is broken.

macports should not use /usr/local at all. It should only link against minimal needed software, otherwise on port -d selfupdate you end up with a disaster.

Change History (13)

comment:1 Changed 17 years ago by markd@…

Cc: cilly@… markd@… added

To the extent that that is possible, MacPortts 1.441 does this by automatically adding -I${prefix}/include -L${prefix}/lib to the default configure flags. But there is no way to force every port to do this since app developers do all sorts of weird things on occasion. And some ports overwrite the defaults since 1.441 because they were written before those defaults were established and need some tweaking so as not to overwrite these defaults. But that must be done on a case-by-case basis, and there is no other way. So I'd say that to the extent that your request is possible, it has already been done. Otherwise, specific bugs on specific ports need to be filed. So this bug should be marked "invalid".

comment:2 Changed 17 years ago by markd@…

Or marked "fixed" depending on what type of fix you were seeking.

comment:3 Changed 17 years ago by cilly@…

Macports for itself should not look in dependencies of /usr/local. I.e. if a user installs readline in /usr/local by hand, the port binary is broken after a selfupdate and removal of readline. To provide a 100% functional port binary it should not be linked against anything in /usr/local; at least there should be an option to stop this behaviour.

comment:4 Changed 17 years ago by markd@…

Are you saying you think this problem can be eliminated globally? There is a bug on the readline problem already. If there were a way to solve the problem we have with readline globally, it has escaped everyone here.

comment:5 Changed 17 years ago by markd@…

The readline ticket is #10651.

comment:6 Changed 17 years ago by cilly@…

This is not only related to readline, macports links itself to openssl, too. I am not sure which other packages it would link.

My suggestion is to tweak the configure-script of macports in that way, that while using port selfupgrade or ./configure, macports does not link against /usr/local.

comment:7 Changed 17 years ago by markd@…

I see no global way to do this. We are trying to find a solution to the readline problem. This can only be done on a case-by-case basis. How does MacPorts link to openssl that needs to be fixed? It needs to be described precisely.

comment:8 Changed 17 years ago by markd@…

Resolution: invalid
Status: newclosed

I'm sorry but I'm going to have to mark this as invalid. There isn't a general solution and if there is a problem with openssl or specific ports we need details about that.

comment:9 Changed 17 years ago by cilly@…

Resolution: invalid
Status: closedreopened

It shouldn't be that difficult to change the configure-script not to look into /usr/local.

comment:10 Changed 17 years ago by markd@…

Resolution: invalid
Status: reopenedclosed

Please specify which ports you are having trouble with. I've fixed problems with a number of ports regarding finding openssl, mysql, and on and on. But it must be done on a case by case basis. Because there is no way to override configure scripts in ports that search for dependencies. Here's why.

Just look through any number of config scripts and you'll find configure scripts like this (Snort configure script):

LDFLAGS="${LDFLAGS} -L/usr/local/lib -L/sw/lib"

There are hard coded paths in configure scripts that are triggered on certain conditions that only the deveopoers know about, and there is no way for MacPorts to anticipate these contingences. The only way to accomplish the task of having no ports that would look in /usr/local would be to contact all the developers for our 4,000 ports and ask them to modify their configure scripts. There is no way for MacPorts to dynamically override all hardcoded paths, nor a way to disallow hardcoded paths.

As I said, we have taken steps just weeks ago to make MacPorts ports strongly prefer to look in /opt/local. 1.440 had significant changes in this regard. Which is another reason we need to know which ports you claim are linking against /opt/local. It sounds like you haven't bothered to check to see if the problem still occurs after 1.440. But, as I said, we can't anticipate globally and in advance when programmers are going to hard code /usr/local or any other path.

comment:11 Changed 17 years ago by cilly@…

Thanks lot for your detailed description.

Now I need some help how to uninstall all ports by macports and install again all ports. How would that be done easily?

comment:12 Changed 17 years ago by markd@…

If you have a large number of ports installed, as you probably do, and you want to go from scratch, just do a "sudo rm -rf /opt/local" and then reinstall the macports binary. Then you'll have MacPorts installed and an empty /opt/local ready to go.

comment:13 Changed 17 years ago by cilly@…

okay, thanks a lot! If I encounter any problems I will file a new ticket. So finally bringing this to an end.

Note: See TracTickets for help on using tickets.