Hello,
to the command
$ otool -L `which mkvmerge`
I got:
/opt/local/bin/mkvmerge:
/opt/local/lib/libmagic.1.dylib (compatibility version 2.0.0, current
version 2.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.8)
/opt/local/lib/libic
Hi,
> This is a know problem and has been a problem for years. Mkvtoolnix
> needs C++11 and has to be built with ... well ... either gcc or
> clang/libc++.
so since semaphore45 uses Snow Leopard his/her mkvtoolnix is built using
GCC against MacPorts' copy of libstdc++ (because the host one doesn'
On Sun, Jun 15, 2014 at 10:46 AM, Clemens Lang wrote:
> Hi,
>
>> On command
>> $ mkvmerge -v -o lplde.mkv cd1.avi + cd2.avi
>>
>> it gave:
>> mkvmerge(36577) malloc: *** error for object 0x7fff70726500: pointer being
>> freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
Hi,
> On command
> $ mkvmerge -v -o lplde.mkv cd1.avi + cd2.avi
>
> it gave:
> mkvmerge(36577) malloc: *** error for object 0x7fff70726500: pointer being
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> Abort trap
>
> Any idea?
That looks a lot like a standard l
Hello all and thanks for committing patches. It seems to have built
successfully, but fails on a simple "merge" operation. As written elsewhere, I
took care to manually install curl and pkgconfig.
On command
$ mkvmerge -v -o lplde.mkv cd1.avi + cd2.avi
it gave:
mkvmerge(36577) malloc: *** error
On Thu, Jun 12, 2014 at 9:16 AM, Clemens Lang wrote:
> Hi,
>
>> > Ideally it would check if the os already provides 1.9 and use that
>> > one if it does, else depend on whatever ruby is already installed
>> > by MP.
>>
>> Isn't that the type of non-reproduceable build that MacPorts tries to avoid?
Hi,
> > Ideally it would check if the os already provides 1.9 and use that
> > one if it does, else depend on whatever ruby is already installed
> > by MP.
>
> Isn't that the type of non-reproduceable build that MacPorts tries to avoid?
No. Either the OS has 1.9, then it's used (and never MacPor
On Thu, Jun 12, 2014 at 2:57 PM, Arno Hautala wrote:
> On Thu, Jun 12, 2014 at 3:08 AM, Mojca Miklavec wrote:
>>
>> Ideally it would check if the os already provides 1.9 and use that
>> one if it does, else depend on whatever ruby is already installed
>> by MP.
>
> Isn't that the type of non-reprod
On Thu, Jun 12, 2014 at 3:08 AM, Mojca Miklavec wrote:
>
> Ideally it would check if the os already provides 1.9 and use that
> one if it does, else depend on whatever ruby is already installed
> by MP.
Isn't that the type of non-reproduceable build that MacPorts tries to avoid?
--
arno s hau
Hi,
On June 12, 2014 9:08:08 AM CEST, Mojca Miklavec wrote:
>Apart from that ... mkvtoolnix from MacPorts never worked for me. It
>crashes because of dependencies being compiled with a different
>compiler.
Maybe that can be fixed using the g++-libc++ script that was recently posted
here? If mkv
On Thu, Jun 12, 2014 at 2:51 AM, Bradley Giesbrecht wrote:
> On Jun 11, 2014, at 5:39 PM, Ryan Schmidt wrote:
>> On Jun 11, 2014, at 7:36 PM, Bradley Giesbrecht wrote:
>>> On Jun 11, 2014, at 5:23 PM, Brandon Allbery wrote:
>>>
>>> Filing an "update" ticket is a good even absent a maintainer. I jus
On Jun 11, 2014, at 5:39 PM, Ryan Schmidt wrote:
>
> On Jun 11, 2014, at 7:36 PM, Bradley Giesbrecht wrote:
>
>> On Jun 11, 2014, at 5:23 PM, Brandon Allbery wrote:
>>
>> Filing an "update" ticket is a good even absent a maintainer. I just bumped
>> the version to 7.0.0 to see if the existin
On Jun 11, 2014, at 7:51 PM, Bradley Giesbrecht wrote:
> On Jun 11, 2014, at 5:39 PM, Ryan Schmidt wrote:
>>
>> On Jun 11, 2014, at 7:36 PM, Bradley Giesbrecht wrote:
>>
>>> On Jun 11, 2014, at 5:23 PM, Brandon Allbery wrote:
>>>
>>> Filing an "update" ticket is a good even absent a maintai
On Jun 11, 2014, at 7:36 PM, Bradley Giesbrecht wrote:
> On Jun 11, 2014, at 5:23 PM, Brandon Allbery wrote:
>>
>> On Wed, Jun 11, 2014 at 7:55 PM, wrote:
>> I wanted to upgrade my MKVToolnix from 6.2.0 to 7.0.0, but it seems it's not
>> compiled for Mac OS X Snow Leopard. For that reason, I
On Jun 11, 2014, at 5:23 PM, Brandon Allbery wrote:
>
> On Wed, Jun 11, 2014 at 7:55 PM, wrote:
> I wanted to upgrade my MKVToolnix from 6.2.0 to 7.0.0, but it seems it's not
> compiled for Mac OS X Snow Leopard. For that reason, I looked into other ways
> to install it, and it seems only Home
On Jun 11, 2014, at 7:23 PM, Brandon Allbery wrote:
> On Wed, Jun 11, 2014 at 7:55 PM, wrote:
> I wanted to upgrade my MKVToolnix from 6.2.0 to 7.0.0, but it seems it's not
> compiled for Mac OS X Snow Leopard. For that reason, I looked into other ways
> to install it, and it seems only Homeb
On Wed, Jun 11, 2014 at 7:55 PM, wrote:
> I wanted to upgrade my MKVToolnix from 6.2.0 to 7.0.0, but it seems it's
> not compiled for Mac OS X Snow Leopard. For that reason, I looked into
> other ways to install it, and it seems only Homebrew has an updated version.
>
I was going to suggest fili
Trace mode (port -t) creates sandboxes during MacPorts operation. This keeps
compiler used by MacPorts from accessing Homebrew, but you have to deal with
Homebrew building against MacPorts. This is why classically only one package
manager is recommended.
On Jun 11, 2014, at 19:55, semaphor...@y
Hello Macports users,
I wanted to upgrade my MKVToolnix from 6.2.0 to 7.0.0, but it seems it's not
compiled for Mac OS X Snow Leopard. For that reason, I looked into other ways
to install it, and it seems only Homebrew has an updated version.
However, it seems to share folders with MacPorts, a
19 matches
Mail list logo
