Bug 16493 – system wide mono/gtk-sharp paths

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Rainer Größlinger (RETIRED) 2003-02-27 14:27:19 UTC]

When merging Mono the following should be set as a system wide path: (preferably
via /etc/env.d/* [?])

MONO_PATH=/usr/lib

and when merging gtk-sharp

LD_LIBRARY_PATH=/usr/lib

should be set because gtk-sharp.dll and the libgtksharpglue.* are in this
directory and some apps (example: http://sky-net.sf.net) fail if those 2 paths
are missing because it can't find the gtk# lib.
I am currently checking out qtc and qtsharp and will be doing an ebuild after
some testing.

[Comment 1 foser (RETIRED) 2003-02-27 16:53:07 UTC]

I dont agree on this one, MONO_PATH is for additional paths, /usr/lib is implicit. And it is easily to circumvent in an ebuild (i think the skynet config script is bit silly on that point).

As far as gtk-sharp goes, its already all in /usr/lib and thats where mono looks anyway (again). So basicly the same answer here. So i kinda fail to see your point. Can you make a more convincing case ?

Skynet is a funny app btw, nice to see the first real app using mono in portage sometime soon.

[Comment 2 Rainer Größlinger (RETIRED) 2003-02-28 07:43:37 UTC]

ok, perhaps some bad research done by me, sorry.

The skynet config script and README gave me the impression that those paths are necessary (if you read it it sounds like "if it fails, make sure the paths are set") and merging mono/gtk# doesn't set any paths and configure scripts can't check where gtk# or qt# is installed without searching for it.

So, I can't make a more convincing case but if your configure script should search what is available that can't be done without the paths if you don't use the standard paths (but since the ebuilds are using them that's obsolete for _us_) but the concern is compatibility:
People just need to make configure scripts which test all possible variations (which might be hard, but anyway ;) since they can't get sure everything is installed in the default location, so setting the paths gives those scripts the compatibility (but again, that's technically not necessary when using the default paths but we have to give scripts acting like these a hint where they can find it [if it's a "check for path but not default location"-script].

I may be wrong on this and I am sure you know what you're doing (and what not ;) but that was the situation I had in mind (since adding those paths doesn't hurt anything else) - again: I may be wrong ;)

[Comment 3 foser (RETIRED) 2003-02-28 07:57:24 UTC]

adding the path is an option ok, but imo it is (for now) unnecessary and redundant. Imo this leads to a -right now unneeded- extra level of complexity (i know this is hardly complex, but look at it as a general case) and that gives for more possible points of failure. Basicly : why make a system more complex when it works as it is.

To make this change for one imo little hackish config script is a no go. But i'll keep it in mind.