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
Fix config paths #1064
Conversation
I tested this and it works great 👍 |
@kumpera can you look at this? |
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 |
@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 |
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). |
@ranma42 you're right, that is the better way to do it. |
Ping! |
Can you send a pull request to bockbuild also? So we can merge them simultaneously. |
@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.
Rebased on current master |
Patch can go it. But since this is a packaging change, @alexischr must be in the loop. |
@alexischr Note that a corresponding PR was sent to bockbuild as well: mono/bockbuild#7 |
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? |
@alexischr ping? |
Sorry guys, I wasn't getting any notification for my being tagged here. These seem great, I'll merge & keep an eye on them. |
Improve handling of lib paths for libMonoPosixHelper and libgdiplus. Fixes #18555.
Update mono config generation to match config path fixes in mono/mono#1064
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. |
see #1937 |
Improve handling of lib paths for libMonoPosixHelper and libgdiplus. Fixes mono/mono#18555. Commit migrated from mono/mono@cdd3d2b
Add bee script to pull down required mono-build-deps from stevedore
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 )