libiconv-select

[jpgoldberg (Jeffrey Goldberg)]

There are a number of closed tickets describing problems outside of MacPorts that result of the libraries installed through libiconv port not behaving as things on the system expect.

Any time I build something outside of MacPorts, I have to look for -liconv and wonder whether I will need to changes that to a full path to the system libinconv.dylib. It is more than tiresome doing that each and every time.

I believe that a libiconv-select, allowing me to select "system" may resolve these problems.

[danielluke (Daniel J. Luke)]

Macports doesn't install things into a location where the linker looks for libraries by default, though - so why are your 'outside of macports builds' picking up the macports libiconv?

[jpgoldberg (Jeffrey Goldberg)]

Macports doesn't install things into a location where the linker looks for libraries by default, though

Hmm. In that case, I've got something misconfigured. Let me see if I've got /opt/local/lib in my "outside of MacPorts" configurations ... I'm not finding it. I don't have CFLAGS or LDFLAGS set in my environment, so I don't know what it was being picked up.

Anyway, if what you say is the case (and I have no reason to doubt you), then feel free to close this issue.

[mouse07410 (Mouse)]

I think it's a bad idea. Because you're going to lose no matter what, as long as some (presumably Macports-installed) software need Macports-installed libiconv, and other packages (like Haskell installed via ghcup) require the system version of libiconv. Because you cannot "select" on a per-package basis, like "use system lib for Haskell package, and Macports lib for everything else".

My solution was to manually edit Haskell configuration file, telling it where to find the system version of libiconv. Nothing else on my machines had any problem, so far.

[mf2k (Frank Schima)]

mouse07410 is correct. -select ports are only meant for user space convenience for bin programs. Any port is not supposed to care what the user preference is and it is considered a bug in the port if it does.

[mouse07410 (Mouse)]

Also, many packages that you compile yourself, don't care which of the two libiconv is the default,as long as you stick with it. They'll just compile against the correct .h files that map the correct function names, and link against the available library. No-brainer.

Only pre-compiled packages (again, like Haskell) may be unhappy with the default, and require special treatment. And again, those packages that include shared libraries dependent on libiconv are simple (if tedious) to remedy.