MAC(.APE) Linux Port 3.99 update 4 released Options

[xmixahlx]

well, the *nix community has support without his help - they will just always be a little shady in the license legality department...


later

[SuperMMX]

new release, mac 3.99 update 4 build 3, this is a bug fix release.

CODE

Version 3.99 update 4 build 3 (2005/04/14)
    * fixed bug of opening files error when no permission to write.
    * changed mac console to be linked dynamiclly.
    * changed LINK definition in Makefile.am of Assembly.

enjoy it.

[xmixahlx]

hi supermmx,

i needed to patch ./configure.in with the following before it would build with the system plugin dir:

CODE

50a51,53
> BMP_INPUT_PLUGIN_DIR=`$PKG_CONFIG --variable=input_plugin_dir bmp`
> AC_SUBST(BMP_INPUT_PLUGIN_DIR)
>

and with the bmp plugin i get this error from beep-media-player (stderr/console) when loading a known-good *ape file

CODE

Oops, something is wrong with the file, error_code = 1002

later

[SuperMMX]

1) Thank you, will be fixed next release. I am sorry, I didn't test it with system dir and i didn't pay enough attention that BMP is different from XMMS. (

2) only with BMP? is XMMS all right with the same versionof MACLib.
there is a bug in Build 2 i metioned in the last post. when opening
ape files that have no write permission, the error 1002 will occur.

please update to Build 3 and try again.

[xmixahlx]

1) no problem. i bumped EXTRA_VERSION up to 1 (so 0.1.0.1) while packaging

2) yes, only with BMP. the XMMS plugin works correctly. i also moved the test *ape file to my home directory, gave it full permissions, and it still displays this error.

i had packaged 3.99u4 build3 first, so this is correct.


later

[SuperMMX]

hmmmmmm, No problem here..

could you test it with the mac command line ?
and if possible, make a little debug to find out the problem. ,

and what's your verion of GCC(including g++), GLIB?
I only test it under gcc 3.3 and 3.4, glib 2.3.2.

Thanks.

This post has been edited by SuperMMX: Apr 15 2005, 14:09

[SuperMMX]

updated version of bmp-mac and xmms-mac

CODE

xmms-mac: Monkey's Audio Codec plugin for XMMS!

Version 0.3.1 (2005/04/28)
       * fixed wrong bitrate displayed in the main window.

CODE

bmp-mac: Monkey's Audio Codec plugin for beep media player!

Version 0.1.1 (2005/04/28)
       * fixed broken building when using the default configuring options.
       * fixed wrong bitrate displayed in the main window.

enjoy it.

[xmixahlx]

thanx for this update, SuperMMX

i apologize, i thought i had replied to you last post - anyways, i have been testing gcc4.0-pre from debian experimental, but also tested gcc3.3 and gcc3.4 before posting the problems.


later

[SuperMMX]

so the problem still there ?? it is really weird.....

what's the version BMP? I tested it with BMP in Debian SID, and
the latest CVS, seems no problem too.

does someone else meet the same problem ?

[gian]

Dear SuperMMX,

just downloaded your lib+xmms plugin, but, as I expected, compilation has a few problems due to my machine architecture (AMD64, with gentoo linux)...

I get the usual warnings about pointer and int getting cast to one another (pointer is 64 bit, while int is 32 on my arch), and this usually leads to segfaults....

Do you know if anyone got the lib and plugin working on 64 bit machines ? In case no one has tried, do you agree if I "touch" your source code in order to get things working (unfortunately with super low priority since I have quite a few other things to do .... unfortunately) ?

thank you

gian

This post has been edited by gian: Apr 30 2005, 17:44

[SuperMMX]

There are some comments in the Monkey's Audio forum about AMD 64 Support. http://www.monkeysaudio.com/smf/index.php?topic=1734.0

Actrually the segfaults are not from these castings, but comes from the assembly sources.

Feel free to modify the source, it is better to make a fine-working patch and
send back to me to be merged in the next release.

[Legoguy]

Hello, thanks for your efforts on this!
However, when loading the plugin with Beep Media Player version 0.9.7, I get this:

CODE

load_inc (this repeated about 50 times)
Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 75: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!

and BMP's window doesn't even show up before the program quits (error 127).

I am running Gentoo linux with gcc 3.4.3 and glibc 2.3.5. I compiled using the standard ./configure --prefix=/usr/local for both mad and bmp-mad.

Removing the plugin removes this problem of course. So there's definitely something wrong.

This is x86 btw, not AMD64.

This post has been edited by Legoguy: May 6 2005, 20:22

[SuperMMX]

what about removing the --prefix option?

I have no idea what the cause is...

[KLJ]

First off, I'd like to thank you for your work on these plugins! It is greatly appreciated.

Second...I believe I may have found a bug in both the bmp and xmms plugins. They both seem to not be able to load files that have a path containing any Japanese characters. (possibly even all asian characters, but I have no way to test that) What makes me think it is the plugins is that if I copy the ape file to a path that dose not contain japanese characters, *poof* it works

The exact error it gives me in both Beep and XMMS is "Invalid MAC File: "/mnt/usbV/Incoming/Music/(album)(japanese albumname)/(Filename).ape"
where (album)(japanesealbumname) is the english album name followed by the japanese name in whatever kana it should be in, and (filename) is the actual name of the file. If I take that same file and copy it to "/mnt/usbV/Incoming/Music" though, it will play quite happily.

Any ideas? Maybe I'm just doing something wrong here, but it does seem rather odd that flac files contained in "/mnt/usbV/Incoming/Music/(album)(japanese albumname)/(Filename).flac" style will play just fine in XMMS (haven't tried them in Beep) where the ape files won't, unless it is a plugin issue.

Again, thanks for your contributions!

[SuperMMX]

if you are in UTF-8 locale, it is the problem, please see the bug:
http://sourceforge.net/tracker/index.php?f...827&atid=699624

this but will be fixed in next release.

[KLJ]

Ah, didn't even think of checking there. I do believe that is the same bug I'm referring to.

Thanks for the response!

[ndn]

trying to install xmms-mac but get this:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking build system type... powerpc-apple-darwin8.1.0
checking host system type... powerpc-apple-darwin8.1.0
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 65536
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin8.1.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common
checking if g++ PIC flag -fno-common works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin8.1.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking whether make sets $(MAKE)... (cached) yes
checking for glib-config... /sw/bin/glib-config
checking for GLIB - version >= 1.2.2... yes
checking for xmms-config... /sw/bin/xmms-config
checking for gawk... (cached) gawk
checking for XMMS - version >= 1.2.4... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking mac/config.h usability... no
checking mac/config.h presence... no
checking for mac/config.h... no
configure: error: *** MAC lib headers not installed - please install first ***


sorry if i'm screwing up, i'm new.

[smthmlk]

trying to install xmms-mac but get this:

[ ... ]

checking mac/config.h usability... no
checking mac/config.h presence... no
checking for mac/config.h... no
configure: error: *** MAC lib headers not installed - please install first ***

You need to compile & install MAC first. That will put the headers in the right place(s). I could be wrong of course, but give it a try

[ndn]

do you know where could i find "MAC"?

[Mr_Rabid_Teddybe...]

do you know where could i find "MAC"?

http://sourceforge.net/projects/mac-port/
or
http://supermmx.org/linux/mac/

[SuperMMX]

currently the main site http://supermmx.org is unavailable, and will last a couple of months,
I am sorry about that. If possible, i will still update the SourceForge site.

[SuperMMX]

mac-port update 4 build 4 released:

CODE

Version 3.99 update 4 build 4 (2005/08/31)
    * added big endian support (really big, and no backward compatibility any more)
    * added library checking for nanosleep.
    * added wcscasecmp checking and copied the corresonding sources from glibc
 for platforms without GNU Extension support.
    * removed -lstdc++ in MACLib/Makefile.am.
    * fixed the bug of conversion from WCS to MBS for non-ascii characters
 in UTF-8 locale.

Since 3.99 update 4 build 4, mac-port has support for big endian platforms,
and has been tested in MAC OSX 10.4, Linux PowerPC and SunOS Sparc,
but need more tests in more OSes and more Platforms.

Please report your bug in SourceForge and add your comments here.

Enjoy it.

[xmixahlx]

* added big endian support (really big, and no backward compatibility any more)

does this mean it no longer supports formats < 3.99? i.e. 3.97?


later

[SuperMMX]

There is a backward compatibility macro definition in the source,

IIRC, it applies to 3.95, (i can't remember that.... sorry, and i am at work now, can't take a look at the source).

This post has been edited by SuperMMX: Sep 2 2005, 07:20

[xmixahlx]

ok, just clairifying what you were referring to


later