Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix config paths #1064

Merged
merged 2 commits into from Jul 14, 2014
Merged

Fix config paths #1064

merged 2 commits into from Jul 14, 2014

Conversation

ranma42
Copy link
Contributor

@ranma42 ranma42 commented May 27, 2014

This patchset should improve the handling of the paths for libgdiplus (by making it more consistent with that of other external libraries, yet preserving the possibility of building & testing Mono with a sibling non-installed libgdiplus) and for libMonoPosixHelper (in particular, fixing https://bugzilla.xamarin.com/show_bug.cgi?id=18555 )

@akoeplinger
Copy link
Member

I tested this and it works great 👍
This finally fixes all my problems with libgdiplus and libMonoPosixHelper when installing Mono to a custom prefix 😄

@alexrp
Copy link
Contributor

alexrp commented Jun 10, 2014

@kumpera can you look at this?

@ranma42
Copy link
Contributor Author

ranma42 commented Jun 10, 2014

Warning: this might change the results of bockbuild. In particular if the path where libgdiplus.dylib is not within the default paths searched by the dynamic linker, it is possible that it would not be found. To overcome this it should be sufficient to build mono with the appropriate --with-libgdiplus=/absolute/path/to/libgdiplus.dylib

@akoeplinger
Copy link
Member

@ranma42 yep, just confirmed with bockbuild, the libgdiplus path in the config file changes with this patch:

- <dllmap dll="gdiplus" target="/Library/Frameworks/Mono.framework/Versions/3.6.0/lib/libgdiplus.dylib" os="!windows"/>
+ <dllmap dll="gdiplus" target="libgdiplus.dylib" os="!windows"/>

Looking at mono-mac-release.py#L220 in bockbuild, I think we need to do the same fixing for libdiplus (as an alternative to passing --with-libgdiplus). But we should be able to get rid of fixing libMonoPosixHelper, as that would point to the correct path with this patch.

@alexrp @kumpera any comments?

@ranma42
Copy link
Contributor Author

ranma42 commented Jun 12, 2014

I would strongly advise to use the --with-libgdiplus argument instead of manually modifying the file. Even if bockbuild and mono are maintained together, using the configure option looks much more robust and allows stronger separation between the two projects (it would be possible, for example, to change the path of that file without modifying bockbuild).

@akoeplinger
Copy link
Member

@ranma42 you're right, that is the better way to do it.

@ranma42
Copy link
Contributor Author

ranma42 commented Jun 23, 2014

Ping!

@alexrp
Copy link
Contributor

alexrp commented Jun 23, 2014

Can you send a pull request to bockbuild also? So we can merge them simultaneously.

@akoeplinger
Copy link
Member

@kumpera @alexrp anything else we need to do for this to go in?

@akoeplinger
Copy link
Member

@ranma42 This needs a rebase.

The libMonoPosixHelper is installed together with Mono, hence its path
in the configuration should be relative to the Mono prefix.

It was previously assumed to reside in a system path, so the the
dynamic linker would find it anyway.

This patch is based on the one included in bug mono#18555 (by Gaëtan
Lehmann <gaetan.lehmann@gmail.com>), but it also updates
runtime/Makefile.am to keep runtime/etc/mono/config consistent.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=18555
Since libgdiplus is not installed together with Mono, it should not be
assumed to be in the same prefix.

The new policy for the --with-libgdiplus configure option is the
following:

 - --with-libgdiplus=/absolute/path/to/libgdiplus.{so,dylib}

   both during build/check and after installation Mono will try to use
   the specified libgdiplus library; the rationale is that when an
   absolute path is given, it can be assumed to be the full path to
   the library that is already installed (possibly in a non-default
   path).

 - default, --with-libgdiplus=no, --with-libgdiplus=installed

   both during build/check and after installation Mono will try to use
   a system-wide libgdiplus library, that is assumed to reside in the
   paths that are automatically searched by the dynamic linker; the
   library is supposed to be already installed in the default path and
   to be useable both during the build and afterwards.

 - --with-libgdiplus=sibling, --with-libgdiplus=yes

   during build/check Mono will try to use the libgdiplus library that
   is assumed to be in the sibling folder (../libgdiplus), but after
   the installation it will try to use a system-wide libgdiplus
   library, that should be in the paths that are automatically
   searched by the dynamic linker; the assumption is that the library
   is not yet installed, but it will go to the default prefix after
   installing it.

 - --with-libgdiplus=../some/relative/path/to/libgdiplus.{so,dylib,la}

   during build/check Mono will try to use the specified libgdiplus
   library, but after the installation it will try to use a
   system-wide libgdiplus library, that should be in the paths that
   are automatically searched by the dynamic linker; the assumption is
   that the library is not yet installed, but it will go to the
   default prefix after installing it.
@ranma42
Copy link
Contributor Author

ranma42 commented Jul 1, 2014

Rebased on current master

@kumpera
Copy link
Contributor

kumpera commented Jul 1, 2014

Patch can go it.

But since this is a packaging change, @alexischr must be in the loop.
Alexis, does this change negatively affect our OSX packaging? If it's ok, could you ensure
that things will remain working after it?

@akoeplinger
Copy link
Member

@alexischr Note that a corresponding PR was sent to bockbuild as well: mono/bockbuild#7

@ranma42
Copy link
Contributor Author

ranma42 commented Jul 5, 2014

If possible I would love to have it merged in time for 3.6, because that would make mono build in Homebrew with no patches. @alexischr do you think it should be ok? Did you encounter any issue?

@akoeplinger
Copy link
Member

@alexischr ping?

@alexischr
Copy link
Contributor

Sorry guys, I wasn't getting any notification for my being tagged here. These seem great, I'll merge & keep an eye on them.

alexischr added a commit that referenced this pull request Jul 14, 2014
Improve handling of lib paths for libMonoPosixHelper and libgdiplus. Fixes #18555.
@alexischr alexischr merged commit cdd3d2b into mono:master Jul 14, 2014
alexischr added a commit to mono/bockbuild that referenced this pull request Jul 14, 2014
Update mono config generation to match config path fixes in mono/mono#1064
@migueldeicaza
Copy link
Contributor

This patch was wrong, it broke support for mono's relocatability support.

My fault for not reviewing this, we are going to have to adopt a different solution.

@lewurm
Copy link
Contributor

lewurm commented Jul 23, 2015

see #1937

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
Improve handling of lib paths for libMonoPosixHelper and libgdiplus. Fixes mono/mono#18555.

Commit migrated from mono/mono@cdd3d2b
AlexKnauth pushed a commit to AlexKnauth/mono that referenced this pull request Nov 2, 2023
Add bee script to pull down required mono-build-deps from stevedore
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants