Lame questions about re-building Lame :)

Hi guys!

I would like to ask you for some hints about porting stuff to AmigaOS 4.x. I've already seen the guide by Spot, but need some additional support. The main issue is that although programming is my primary skill, I've been rarely using GCC. Microsoft Visual Studio made me somehow 'lazy' ;)

My goal for now is to learn how to properly set up a GCC AmigaOS 4.1 enviroment - basing on a existing piece of a software (in other words: on something that should already have been working...). I've downloaded Lame 3.99.5 sources and were trying to compile them. It even does, but the builded lame tool crashes when trying to encode file...
I assume, that the sourceforge lame repository contains all the needed changes and my problem are only about correctly using compile switches...

Just to point out my questions:
- Are Lame Sourceforge sources valid for AmigaOS 4.1?
- Could someone point me a comprehensive, complete way to build Lame for AmigaOS 4.1 from SourceForge sources?
- There're several pre-made make files. Some of them contains 'Amiga' parts. Is it fine to use them, or do I need to use 'configure' to create new 'make'?
- 'configure' based 'frontend makefile' needs to be corrected. By default the 'libmpgdecoder.la' is not in a scope preventing the code to build. ... Why I need to correct that? Did I miss a platform related switch that influences project paths?
- some lame makefiles contains AmigaOS variants too, but I think, that they may be only valid in a 68k and PUP/WOS. Is that fine for a AmigaOS4 too? If not - how it should be defined?

Thank you in advance,
Radov

PS. Wanted to place this message on the OS4Coding.net, but apparently I'm unable to post a new content there...

have you tried with a big stack? stack 5000000 or so?

have you tried with a big stack? stack 5000000 or so?

Yeap. That was the first thing i've tried.
My Lame build crashes because of a DSI error. Disassembly shows an attempt to access memory at '0x00000000'. It shouldn't be hard to track it in the sources, but I would like not to take such approach now:)

As I wrote in the first message, my goal is to to learn how to properly setup AmigaOS 4.1 enviroment: re-use already ported sources, learn best practices and such... Lame 3.99.5 should have its sources already compatible with AmigaOS 4.1 and I should have a knowledge how to properly configure and make a use of them. Tracking bugs is, in this case, an one time solution. If this job has already been done and only need to be 'activated' by certain basic compile-time args, I would like to ask for some hints about:)

I have taken some attempts, deleted '-pipe', declared some other flags (maybe in a wrong way? or in a wrong place?) but with sam effect. Maybe I'm wrong and the sources are not valid, so I have no chance at all to reach my goal? At this point I'm unable to get the answers by myself ;)

I'm the porter/uploader of LAME that's on OS4Depot at the moment, and the upload before that. If I remember correctly, on the version before 3.99.5, I couldn't run it either unless I applied the 3rd party Altivec patches, and then compiled it *without* altivec.

The altivec ports I've tried to do haven't worked (I don't have an altivec supported system, but had other people test), yet applying these 3rd party patches, then compiling without altivec, allowed the generic version to work for me.

I can't remember if I used the straight sourceforge sources for 3.99.5. I might have applied the altivec patches anyway, then compiled with altivec support disabled. Also keep in mind I compiled it with the latest OS4 SDK of the time.

I think you should try a different base program to test your compiling environment & skills. Perhaps try faad2.

If you're going to make shared libraries, you'll need to edit libtool after running configure, to change deplibs_check_method to pass_all and version_type to freebsd-elf, and edit the Makefile to link with -use-dynld. Using -lunix can be handy sometimes, if you want to test things with unix-style paths. On occasion a configure script will build something that requires unix-style paths to continue with the rest of the configuring. In that case use LIBS="-lunix" at the end of the configure line.

Sometimes you'll run across older configure scripts that aren't ready for OS4 shared libs; If that's the case, merge & splice code from a more recent configure script from a different/newer source.