Requested munt-mt32emu port file

[Dominik Reichardt]

Hi all,

yesterday I requested a port of Munt’s mt32emu library (munt.sourceforge.net 
)  at https://trac.macports.org/ticket/62166 
 and just added a working portfile 
https://trac.macports.org/attachment/ticket/62166/Portfile 
. 

What I didn’t manage to do:

- *kind of* had to hard code the master_sites link. I noticed other projects 
use “sourceforge:project/projectname” but however I did this it either did not 
find anything or grabbed a webpage.

- provide both a shared and static version of the library. By default a shared 
library gets build while you need to pass "-Dlibmt32emu_SHARED=FALSE” for the 
static one. But it’s either or, not both at the same time. I don’t know whether 
there is a way for two configure/build phases in one port file. But the shared 
one is the most important one anyway and if you think it is worthwhile to 
pursue, I can ask the Munt developer whether he could make it possible to have 
both.

Otherwise the library portfile is ready to be used I think (quick test worked 
on my system).

I am aiming to create a port file for the two Munt programs as well, but that 
is maybe a bit more of a challenge as the GUI program mt32emu-qt can be build 
against either QT4 and QT5 (other than that it is very straightforward with 
dependency on glib2 and optional JACK and Portaudio)

Cheers,

Dom

Re: Using X11 for an older program

[Dominik Reichardt]

Hi,

download and install xquartz from https://www.xquartz.org 
. This is the semi-official X11.app replacement. Did 
not get an update for four years now but it brings the needed libraries and 
installs in /opt/x11.

Good luck! :)

Dominik

> On 22. Dec 2020, at 08:50, Michael  wrote:
> 
> 
> On 2020-12-21, at 8:38 PM, Ken Cunningham  
> wrote:
> 
>> A thought — perhaps you might just take the easy road, and install the 
>> libraries it is looking for, in /opt/X11
>> 
>> what is that, XQuartz? 
> 
> Except that the current version of XQuartz is, as I understand it, what 
> Macports provides.
> 
> i.e. -- my choice is either an 8 year old apple build, or a current Macport 
> build.
> 
> (If I'm wrong here, please tell me.)
> 
>> 
>> K
>> 
>>> On Dec 21, 2020, at 7:01 PM, Michael  wrote:
>>> 
>>> OK. Next question: Is there any reason I cannot install libpng version 15 
>>> at the sametime?
>>> 
>>> I am aware that there is a non-versioned link file, that the latest version 
>>> of the dynamic library installs. That can stay at 16 where it belongs. I 
>>> mean specifically having both the libpng15 and the libpng16 files.
>>> 
>>> I am very surprised at linking to a specific version of a dynamic library. 
>>> This is actually commercial software, and it did not link to generic 
>>> "libpng", nor to generic "libpng15" -- linking to a specific version of a 
>>> dynamic library? Isn't the whole point of dynamic libraries that you don't 
>>> get a single specific buggy version, but the latest non-buggy version?
>>> 
>>> On 2020-12-21, at 6:55 PM, Ken Cunningham  
>>> wrote:
>>> 
> On 2020-12-21, at 10:55 AM, Michael  wrote: > 
> This should be a simple one. I hope. 
>> 
>> I just installed a program that was compiled against the release version 
>> of mac's X11. Crashes on startup with this: 
>> 
>> dyld: launch, loading dependent libraries 
>> 
>> Dyld Error Message: 
>> Library not loaded: /opt/X11/lib/libpng15.15.dylib 
>> 
>> What symbolic links do I need? /opt has no X11 directory. 
> Ok, another question. I found this: /opt/local/lib/libpng16.16.dylib I 
> cannot find the older version. What do I need to do to install both the 
> current and the older version of this library at the same time? 
 
 There are likely to be more libraries missing after you fix this one, but 
 you can try.
 
 EIther symlink a real library that is the same or as similar as you have 
 into the position being looked for:
 
 sudo ln -s /opt/local/lib/libpng16.16.dylib /opt/X11/lib/libpng15.15.dylib
 
 or
 
 use install_name_tool to change /opt/local/lib/libpng16.16.dylib to 
 /opt/X11/lib/libpng15.15.dylib in your binary.
 
 install_name_tool -change  /opt/local/lib/libpng16.16.dylib 
 /opt/X11/lib/libpng15.15.dylib /path/to/my/binary
 
 
 You can see that there are many many ways this could break / not work at 
 all. 
 
 But it sometimes works, if you’re lucky, and the libraries are very close 
 to what is being looked for.
 
 K
>>> 
>>> ---
>>> This message was composed with the aid of a laptop cat, and no mouse
>>> 
>> 
> 
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
> 

Re: local *single* Portfile

[Dominik Reichardt]

> On 7. Dec 2020, at 17:54, Kevin Reid  wrote:
> 
> On Mon, Dec 7, 2020 at 3:10 AM Dominik Reichardt  <mailto:domi...@gmail.com>> wrote:
> I need to test whether a patch for cairo helps for a severe crash bug when 
> you build against it with macOS SDK 11.0.
> (see https://gitlab.freedesktop.org/cairo/cairo/-/issues/420 
> <https://gitlab.freedesktop.org/cairo/cairo/-/issues/420> and the pull 
> request !52 <https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/52>)
> 
> As Cairo, its dependencies as well as GTK+3 (+ dependencies) is all done via 
> MacPorts, I wonder if I can do this via local port file + local code. I dimly 
> remember doing something like this years ago and I didn’t need to do all of 
> the 4.6. Local Portfile Repositories 
> <https://guide.macports.org/chunked/development.local-repositories.html> 
> steps (and especially where and how to reference local source repository 
> alludes me).
> 
> To install a single modified port, all you need to do is have the Portfile 
> (and any patches, etc.) in some directory, then run sudo port install (with 
> no port name argument) from that directory.

Thank you, that helps the first step, but does it need to be a patch with 
source in the net, or can I manage this with local source as well?

local *single* Portfile

[Dominik Reichardt]

Hi all,

I need to test whether a patch for cairo helps for a severe crash bug when you 
build against it with macOS SDK 11.0.
(see https://gitlab.freedesktop.org/cairo/cairo/-/issues/420 
 and the pull request 
!52 )

As Cairo, its dependencies as well as GTK+3 (+ dependencies) is all done via 
MacPorts, I wonder if I can do this via local port file + local code. I dimly 
remember doing something like this years ago and I didn’t need to do all of the 
4.6. Local Portfile Repositories 
 steps 
(and especially where and how to reference local source repository alludes me).

Can you give me pointers? I will use the cairo-devel portfile as reference and 
just up the revision to be able to quickly add and discard it again.

Thanks,

Dom

Re: macOS 11 Big Sur and MacPorts

[Dominik Reichardt]

> On 16. Nov 2020, at 10:05, Wahlstedt Jyrki  wrote:
> 
> 
> 
>> Dominik Reichardt mailto:domi...@gmail.com>> kirjoitti 
>> 16.11.2020 kello 10.55:
>> 
>> In Xcode itself I actually do not see the CLT listed at all, only the 
>> simulators.
>> 
> I have mine here:
> 
> 

Indeed, there it is, thanks :)

Re: suddenly, "-arch i386" is added and all fails: e.g. libsdl (dosbox is i386 only)

[Dominik Reichardt]

> On 7. Mar 2020, at 18:30, Ken Cunningham  
> wrote:
> 
>> As I was one of those with in depth view on DOSBox and previously adamant on 
>> leaving it on i386:
>> 
>> - the best 64bit support, meaning the fastest, is in current SVN of DOSBox. 
>> The 0.74-3 release is ok but very slow.
>> 
>> - IMHO, do NOT use the fork of DOSBox for SDL2 unless that particular branch 
>> is adding *only* SDL2 stuff. Otherwise it brings many more enhancements that 
>> might clash eventually with the goals of DOSBox itself.
>> 
> 
> Seems you know a lot, and I know little, about the inner workings.
> 
> Want to collaborate? I can do  the MacPorts things easily.
> 
> Or just take it over?
> 
> 
> Here are the issues I saw:
> 
> 1. we need a 64bit build
> 2. when I last tried the 64 bit build on Mojave, it was unusable due to the 
> white screen for SDL, ergo the SDL2 version
> 
> 
> Please advise on optimal plan!
> 
> Ken

I’m not sure I can take it over. I played with this idea before but real life 
always interrupted and set me back on my other projects. I do have a buildbot 
running that generates a new snapshot of DOSBox SVN with each commit to the SVN.
Since the buildbot runs on OS X 10.11 I averted the white (or desktop mode 
color on Catalina) screen as a pre Mojave build of SDL 1.2x does not run into 
that problem.
This problem can be circumvented by setting the DOSBox output to opengl (which 
is also way faster than the other outputs). 

BUT I’ve run into another problem, namely that if I build DOSBox against an SDK 
< 10.14 the opengl output would eventually crash the whole graphics system of 
the mac *if* the graphics chip is by Intel or Nvidia. I have not yet correctly 
resolved this for my snapshots mostly because the only non-amd mac the DOSBox 
devs and me have access to is my wife’s macbook. And she hates it when I test 
on it (which will result in a hard crash when my test fails).

There is another, less invasive, SDL2 patch that might work better, but the 
biggest problem of any SDL2 patch for DOSBox is libSDL_Sound. For SDL 1.2x 
liSBL_sound works well enough. But the SDL2 port of libsdl_sound is not working 
correctly (e.g. skipping sound at times) and is not setup in a working way (the 
libsdl2_sound header is not where it is supposed to be). But if you build the 
non-ported last libsdl_sound release against SDL2 everything is named wrong 
(not adding the 2 of SDL2) and thus clashing with a SDL 1.2x build of 
libsdl_sound.
Not to mention that AFAIK there is no SDL2 port of libsdl_sound in MacPorts.

So, I think, best try if 0.74-3 is working for you on 10.14/.15. It *should* 
have the output default set to opengl and works for me on 10.15 out of the 
“box” build against macports’ libs and headers.
Speedwise it is *okay* in 64bit. The big optimization is in SVN, though (a dos 
benchmark running in SVN is getting 160-180fps, while Dosbox 0.74-3 is getting 
around 80fps). You could consider adding a DOSBox-devel port that gets its 
source from SVN (and which needs a tiny patch to set the default output to 
opengl). But AFAIK getting the sources from a repository is not that popular 
with the MacPorts devs.


Cheers,
Dom

Re: suddenly, "-arch i386" is added and all fails: e.g. libsdl (dosbox is i386 only)

[Dominik Reichardt]

As I was one of those with in depth view on DOSBox and previously adamant on 
leaving it on i386:

- the best 64bit support, meaning the fastest, is in current SVN of DOSBox. The 
0.74-3 release is ok but very slow.

- IMHO, do NOT use the fork of DOSBox for SDL2 unless that particular branch is 
adding *only* SDL2 stuff. Otherwise it brings many more enhancements that might 
clash eventually with the goals of DOSBox itself.

> On 7. Mar 2020, at 17:49, Ken Cunningham  > wrote:
> 
> 
> I just updated the dosbox and dosbox-sld2 ports in my personal repo to the 
> latest versions
> 
> please feel free to give them a try. they work for me
> 
> if they work well enough for everyone, I can move them over into the main 
> macports repo.
> 
>  >

> On 7. Mar 2020, at 17:49, Ken Cunningham  
> wrote:
> 
> 
> I just updated the dosbox and dosbox-sld2 ports in my personal repo to the 
> latest versions
> 
> please feel free to give them a try. they work for me
> 
> if they work well enough for everyone, I can move them over into the main 
> macports repo.
> 
> 

Re: dosbox update?

[Dominik Reichardt]

I’m ready to help with DOSBox, since I’ve dealt with it a lot through the years 
and am using MacPorts for other things and at least know how to read a port 
file. BUT for the snapshots I’m not using MacPorts but instead build a 
minimalistic prefix for the snapshots I am doing (Exult, Pentagram, Nuvie, Xu4, 
DOSBox) and am using a bash script. All that on an old MacMini that I’m using 
as a buildbot when new code is committed to those projects :)

The 0.74-2 release of DOSBox does not need any of the previous patches. Qbix 
(main developer of DOSBox) looked over the MacPorts patches.

As I’m writing this while your new replies came in, your port file looks good 
and ready.

Forcing a 64bit build is likely the best because easiest, unless a SDK trick 
becomes available. Either way we only have a one year grace period anyway.

As for building with older SDK and make it work on newer OSX versions is what I 
am doing for years now. Mix matching binaries with arches built against 
different SDKs did not pose any problem. I’m still build for ppc on 10.13 
through a copy of Xcode 3 n my hard drive.

The other emulators just need to find a way to speed up their 64bit code 
somehow, or we are out of luck next year :(

Dom

> On 4. Oct 2018, at 17:14, Ken Cunningham  
> wrote:
> 
> Sounds like you're all over this.
> 
> We can keep the 32bit builds on PPC and all Intel systems prior to Mojave. 
> The patches and Portfile might need to be tweaked for the current release.
> 
> For Mojave, we have two options:
> 
> 1. force a 64bit build no matter what (easy)
> 
> 2. do an SDK trick with MacOS.10.13.sdk so it builds 32bit on Mojave (pretty 
> easy, but required manual intervention)
> 
> 
> Personally, I'd do them both -- make 32bit Mojave a variant maybe.
> 
> Are you interested in helping out James Slor with this? He is around 
> occasionally, very rarely these past couple of years?
> 
> 
> BTW I have exactly the same questions about what I'm going to do with 
> basiliskii, sheepshaver, and other emulators that work better 32bit.
> 
> Ken
> 
> 
> 
> 
> On 2018-10-04, at 1:55 AM, Dominik Reichardt wrote:
> 
>> The developers of DOSBox know that it needs to improve but it’s not an easy 
>> task. And yes, you are right for most things the 64bit performance is more 
>> than enough and the more power the host machine has the less noticeable it 
>> is. Only the “latest” Dos games, most prominent the build engine games 
>> (Blood, DukeNukem 3D, Shadow Warrior…), might tax your system.
>> 
>> Btw, I did the 0.74-2 release build of DOSBox which still runs on OS X 10.4 
>> - 10.13 (and likely on 10.14, too, but I did not have a chance to test). And 
>> I’m also doing straight unmodified snapshots when SVN changes at 
>> https://www.dropbox.com/s/kbrf5elbcu66kst/Dosbox-Snapshot.dmg?dl=1 
>> <https://www.dropbox.com/s/kbrf5elbcu66kst/Dosbox-Snapshot.dmg?dl=1> - all 
>> in ppc (10.4/10.5) and 32/64bit.
>> 
>> Dom
>> 
>>> On 4. Oct 2018, at 10:39, Richard L. Hamilton >> <mailto:rlha...@smart.net>> wrote:
>>> 
>>> One might hope that could get a little better in time.  But I imagine it's 
>>> still faster than the ancient systems it emulates, so aside from power 
>>> usage e.g. on a laptop, presumably it's still usable for most purposes, if 
>>> not ideal.
>>> 
>>>> On Oct 4, 2018, at 03:36, Dominik Reichardt >>> <mailto:domi...@gmail.com>> wrote:
>>>> 
>>>> JFYI, while the 64bit DOSBox now builds and runs correctly, the 
>>>> performance penalty is still enormous. DOSBox built in 64bit is running at 
>>>> roughly 55% of a 32bit build.
>>>> 
>>>> Dom
>>>> 
>>>>> On 4. Oct 2018, at 02:39, Ken Cunningham >>>> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>>>> 
>>>>> I have the update done and I'm using it now.
>>>>> 
>>>>> Just working out the final dets.
>>>>> 
>>>>> Ken
>>>>> 
>>>>> On 2018-10-03, at 4:23 PM, Richard L. Hamilton wrote:
>>>>> 
>>>>>> On www.dosbox.com <http://www.dosbox.com/>, I see
>>>>>> 
>>>>>> Thursday, August 30th, 2018 - Qbix 
>>>>>> DOSBox 0.74-2 has been released! 
>>>>>> 
>>>>>> A maintenance release for DOSBox 0.74, which solves the following 
>>>>>> problems: 
>>>>>> Windows: Fix auto/max cycles algorithm on Windows 7, which helps with 
>>>>>> stuttering audio.
>>>>>> Mac OS X: Bring a 64 bit version and improve performance.
>>>>>> Linux: Fix the 64bit dynrec cpu core and a lot of compilation problems. 
>>>>>> Add patches for the WINE Team.
>>>>>> 
>>>>>> The game compatibility should be identical to 0.74. 
>>>>>> 
>>>>>> We have saved all game fixes for the upcoming 0.75 release, which will 
>>>>>> enter regression testing soon. This release has been created so you can 
>>>>>> go back to 0.74-2, in case we happen to break your favourite game in 
>>>>>> 0.75.
>>>>>> 
>>>>>> 
>>>>>> Has anyone tried this yet?  Given Mojave, a 64-bit version that works 
>>>>>> and performs acceptably would be good!
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: dosbox update?

[Dominik Reichardt]

The developers of DOSBox know that it needs to improve but it’s not an easy 
task. And yes, you are right for most things the 64bit performance is more than 
enough and the more power the host machine has the less noticeable it is. Only 
the “latest” Dos games, most prominent the build engine games (Blood, DukeNukem 
3D, Shadow Warrior…), might tax your system.

Btw, I did the 0.74-2 release build of DOSBox which still runs on OS X 10.4 - 
10.13 (and likely on 10.14, too, but I did not have a chance to test). And I’m 
also doing straight unmodified snapshots when SVN changes at 
https://www.dropbox.com/s/kbrf5elbcu66kst/Dosbox-Snapshot.dmg?dl=1 
<https://www.dropbox.com/s/kbrf5elbcu66kst/Dosbox-Snapshot.dmg?dl=1> - all in 
ppc (10.4/10.5) and 32/64bit.

Dom

> On 4. Oct 2018, at 10:39, Richard L. Hamilton  wrote:
> 
> One might hope that could get a little better in time.  But I imagine it's 
> still faster than the ancient systems it emulates, so aside from power usage 
> e.g. on a laptop, presumably it's still usable for most purposes, if not 
> ideal.
> 
>> On Oct 4, 2018, at 03:36, Dominik Reichardt > <mailto:domi...@gmail.com>> wrote:
>> 
>> JFYI, while the 64bit DOSBox now builds and runs correctly, the performance 
>> penalty is still enormous. DOSBox built in 64bit is running at roughly 55% 
>> of a 32bit build.
>> 
>> Dom
>> 
>>> On 4. Oct 2018, at 02:39, Ken Cunningham >> <mailto:ken.cunningham.web...@gmail.com>> wrote:
>>> 
>>> I have the update done and I'm using it now.
>>> 
>>> Just working out the final dets.
>>> 
>>> Ken
>>> 
>>> On 2018-10-03, at 4:23 PM, Richard L. Hamilton wrote:
>>> 
>>>> On www.dosbox.com <http://www.dosbox.com/>, I see
>>>> 
>>>> Thursday, August 30th, 2018 - Qbix 
>>>> DOSBox 0.74-2 has been released! 
>>>> 
>>>> A maintenance release for DOSBox 0.74, which solves the following 
>>>> problems: 
>>>> Windows: Fix auto/max cycles algorithm on Windows 7, which helps with 
>>>> stuttering audio.
>>>> Mac OS X: Bring a 64 bit version and improve performance.
>>>> Linux: Fix the 64bit dynrec cpu core and a lot of compilation problems. 
>>>> Add patches for the WINE Team.
>>>> 
>>>> The game compatibility should be identical to 0.74. 
>>>> 
>>>> We have saved all game fixes for the upcoming 0.75 release, which will 
>>>> enter regression testing soon. This release has been created so you can go 
>>>> back to 0.74-2, in case we happen to break your favourite game in 0.75.
>>>> 
>>>> 
>>>> Has anyone tried this yet?  Given Mojave, a 64-bit version that works and 
>>>> performs acceptably would be good!
>>>> 
>>> 
>> 
> 

Re: dosbox update?

[Dominik Reichardt]

JFYI, while the 64bit DOSBox now builds and runs correctly, the performance 
penalty is still enormous. DOSBox built in 64bit is running at roughly 55% of a 
32bit build.

Dom

> On 4. Oct 2018, at 02:39, Ken Cunningham  
> wrote:
> 
> I have the update done and I'm using it now.
> 
> Just working out the final dets.
> 
> Ken
> 
> On 2018-10-03, at 4:23 PM, Richard L. Hamilton wrote:
> 
>> On www.dosbox.com , I see
>> 
>> Thursday, August 30th, 2018 - Qbix 
>> DOSBox 0.74-2 has been released! 
>> 
>> A maintenance release for DOSBox 0.74, which solves the following problems: 
>> Windows: Fix auto/max cycles algorithm on Windows 7, which helps with 
>> stuttering audio.
>> Mac OS X: Bring a 64 bit version and improve performance.
>> Linux: Fix the 64bit dynrec cpu core and a lot of compilation problems. Add 
>> patches for the WINE Team.
>> 
>> The game compatibility should be identical to 0.74. 
>> 
>> We have saved all game fixes for the upcoming 0.75 release, which will enter 
>> regression testing soon. This release has been created so you can go back to 
>> 0.74-2, in case we happen to break your favourite game in 0.75.
>> 
>> 
>> Has anyone tried this yet?  Given Mojave, a 64-bit version that works and 
>> performs acceptably would be good!
>> 
> 

Re: User information about macOS Mojave

[Dominik Reichardt]

Am 28.09.2018 um 18:50 schrieb Thomas Bodlien 
:

>> 
>> Well, on second thought, if you want to generate 32bit executables with the
>> newest compilers, it should be possible to build LLVM 7.0 and use it with
>> the MacOS 10.13 SDK. So, no need to be limited to older compiler versions.
>> And I think that's in fact what I'm going to do in Mojave.
>> 
>> César
> 
> 
> But why?
> What do you need 32-Bit Support for?
> 

Performance? For example DOSBox is three times faster in 32bit ;)

But in general, these questions are pointless. Some years ago the question was 
"what do you need 64bit support for" when peoole asked for it...

Re: User information about macOS Mojave

[Dominik Reichardt]

At least for command line building of things this will be a way to keep old 
xxode around.

> Am 27.09.2018 um 12:08 schrieb Ces VLC :
> 
> 
> 
> On Thu, Sep 27, 2018 at 12:01 PM Richard L. Hamilton  
> wrote:
> >
> > Clearly you can install 9.4.1 on Mojave...and it seems to work at least for 
> > trivial code, even compiling to 32 bit:
> [...]
> > I have both installed, and simply switched the command line instances with
> > [...]
> 
> Thanks! I didn't consider installing both, but it could be a nice idea! 
> Thanks!
> 
> César
> 

Re: anything that only builds 32-bit?

[Dominik Reichardt]

Notable 32bit only is DOSBox. It builds in 64bit but performance drops by 90%

> Am 07.01.2018 um 04:56 schrieb Richard L. Hamilton :
> 
> Given that 32-bit support may be reduced by future OS versions, it would be 
> good to know what ports or variants only build 32-bit.
> 
> If there is already a list, a pointer to a list or a way to discover this, it 
> might be FAQ-worthy given the circumstances.
> 
> 

Re: High Sierra and MacPorts

[Dominik Reichardt]

I don't know what went wrong but I didn't see the announcement here in the user 
list, nor the announcement for the previous release.
And at least for 2.4.2 neither did the list archive 
https://lists.macports.org/pipermail/macports-users/2017-October/date.html


> Am 12.10.2017 um 10:28 schrieb Chris Jones :
> 
> 
> 
>> On 12/10/17 09:27, Chris Jones wrote:
>>> On 12/10/17 00:04, Dave Horsfall wrote:
 On Mon, 9 Oct 2017, Dave Horsfall wrote:
 
 Now that MacPorts is on 2.4.2, is High Sierra now fair game?  Is it likely 
 to be even more bloated and slower on my old 4GB MacBook than before?
>>> 
>>> Well, that generated a fascinating discussion, but it didn't answer my 
>>> questions...  If there was an announcement about MacPorts 2.4.2 then I 
>>> guess I must've missed it.
>> Yes, you did miss it. The announcement was sent out on the 8th Octo to both 
>> the user and devel lists. Search for the message "MacPorts 2.4.2 has been 
>> released" which I guess is clear enough ;)
> 
> Correction... It was sent to the users and *announce* mailing lists.

Re: Retro -- Tiger/Leopard PPC - libsdl2 infrastructure now available

[Dominik Reichardt]

Thanks, I'm offering snapshots for some SDL based stuff and if possible I still 
offer a universal build with ppc support.
Having SDL2 is great.

What's the holdup with SDL2? Upstream is about to release a new version any day 
now and that will be 2.0.6.

Thanks

Dom

> Am 06.07.2017 um 09:38 schrieb Ken Cunningham 
> :
> 
> For those of you with some PPC systems around, the libsdl2 infrastructure 
> (libsdl2, libsdl2_image, libsdl2_net, libsdl2_mixer, libsdl2_ttf) is a 
> collection of supporting ports for a number of other ports, a lot of the them 
> games, emulators, etc.
> 
> I finished porting the last of these items back to Tiger & Leopard PPC, and 
> all appear to work correctly. This might open the door up for some other 
> software you were hoping to install (like Pingus, for example, which works 
> nicely).
> 
> For the moment, you can install the libsdl2 infrastructure from  this repo 
>  if you’re interested.
> 
> We’ll see what ports work and what doesn’t in the end, but libsdl is 
> reasonably current at 2.0.3, and the others are the current versions, so we 
> might be successful.
> 
> Best,
> 
> Ken

Re: A question on dynamic linking / version-changing libraries

[Dominik Reichardt]

> On 6 Mar 2017, at 09:53, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:
> 
> 
> Building statically is also a security nightmare.
> 
> If I have a dynamic libFoo.so, that a lot of other libraries and applications 
> dynamically link against, that is suddenly found to have a major security 
> bug, then once libFoo.so is updated I know everything else using it is also 
> fixed. If instead it where a static libFoo.a then its a nightmare as you then 
> have to make sure *everything* that could possibly have used it got updated. 
> There are reasons we don't generally statically link anymore, and they are 
> good reasons.
> 

Good point. Thank you. I’m providing OS X snapshots for a couple of game things 
and linking statically is the best I have come up with and these don’t have 
such security concerns but I’ll keep that in mind.

> The reasons MP does not have anything like frameworks is simply because such 
> an idea does not really exist in the Linux/OSS world and as MP is essentially 
> just a packaging system for that, thats what we get. Theoretically, could 
> such a system exist there ? yes, of course. Will it ever... Highly unlikely.
> 
> On 05/03/17 20:07, Dominik Reichardt wrote:
>> Oh you can build stuff statically but that is a kind of manual work and not 
>> for MP to do.
>> 
>>> On 5. Mar 2017, at 19:47, Michael <keybou...@gmail.com> wrote:
>>> 
>>> 
>>>> On 2017-03-05, at 9:49 AM, Brandon Allbery <allber...@gmail.com> wrote:
>>>> Also fixed-*path* libraries are part of the Mach-O format and the tooling 
>>>> does not exist to override this well...
>>> 
>>> Is this why a program compiled against a brew installation of qt5 in 
>>> /usr/opt won't work with a ports installation of qt5 in /opt/local, and 
>>> visa-versa?
>>> 
>>> Is there really no way around this -- no way to say "This program wants qt5 
>>> in whatever this system says is the local path of libraries"? No equivalent 
>>> of $PATH for libraries?
>>> 
>>> ... OK, is there any way - at all - to have a program compiled with either 
>>> brew or ports that will run on an arbitrary OSX that might not have either? 
>>> (i.e. -- fully built and contained)?
>>> 

Re: A question on dynamic linking / version-changing libraries

[Dominik Reichardt]

Oh you can build stuff statically but that is a kind of manual work and not for 
MP to do.

> On 5. Mar 2017, at 19:47, Michael  wrote:
> 
> 
>> On 2017-03-05, at 9:49 AM, Brandon Allbery  wrote:
>> Also fixed-*path* libraries are part of the Mach-O format and the tooling 
>> does not exist to override this well...
> 
> Is this why a program compiled against a brew installation of qt5 in /usr/opt 
> won't work with a ports installation of qt5 in /opt/local, and visa-versa?
> 
> Is there really no way around this -- no way to say "This program wants qt5 
> in whatever this system says is the local path of libraries"? No equivalent 
> of $PATH for libraries?
> 
> ... OK, is there any way - at all - to have a program compiled with either 
> brew or ports that will run on an arbitrary OSX that might not have either? 
> (i.e. -- fully built and contained)?
>