Re: [Astlinux-users] Rhino compile problem (0.4 branch)

[Darrick H. <dha...@dj...>]

Sebastian Auriol wrote:
> Darrick Hartman wrote:
>   
>> Sebastian,
>>
>> I'm not going to reply to each of the individual compile
>> errors you are
>> receiving.  I will try to address most of them here.
>>
>> 1).  even though it should work, currently "make
>> <package>-clean" then
>> trying to remake that same package will probably result in
>> errors.  Some
>> of the packages have interdependancies.  The guaranteed way
>> which will
>> work is to remove the build_i586 directory.  We are trying to address
>> this in trunk, but it will not be fixed in the 0.4 branch.  There are
>> just too many issues to try to fix them all with our limited
>> resources. 
>>     
>
> The only package I have used "make clean" on is the linux package (done from
> the folder in build_i586). AFAIK this is the only solution in order to get
> the kernel to re-compile after changing the kernel build options. Please
> correct me if there is another, better, way.
>   
Several packages require the kernel (linux package) to be built first.  
If you remove the kernel, you also need to remove wanpipe, zaptel, 
madwifi ... The only SAFE way to do this is remove the entire build_i586 
tree.  I apologize for that, but it's the only safe way.  If you have a 
reasonably fast processor it shouldn't take more than 30 minutes to 
build the entire thing anyway.
>> 2).  Kristian and I both built 0.4 from scratch (less the
>> toolchain) in
>> the last day or so and neither of us had problems.  I suspect
>> that your
>> problems are related to #1.
>>     
>
> I am not the only one to have wanpipe not compile on them from last night's
> svn - Manuel also had this. The iaxmodem problem was after another make
> after touching some files to make the wanpipe package believe it had been
> built, so I suppose it could be due to that.
>   
I suspect that both you and Manuel are doing the same thing.  I doubt 
the 0.4 branch will ever reach a point where "make <package-foo>-clean 
will work as well as we'd like it to.  This is why I've stated several 
times that you should remove the build_i586 directory if you are 
changing things in your target packages.
>> 3).  rhino is known not to work.  That's why I have it flagged as
>> testing/experimental.  They have not released the driver
>> publicly yet.
> I don't wish to rude, but why update the rhino package in the stable branch
> if it was working before and the new version is known not to work?  Can I
> simply revert to using the old version of the rhino package?  Are there
> known issues with the older version?  If so, what are they?
>   
The old rhino package was outdated and didn't work with the updates to 
zaptel.  It was based on zaptel 1.2.7.  Rhino Equipment supplies the 
download.  Their old download would not work with newer versions of 
zaptel without changing the patch.  We decided that it would be better 
for Rhino to provide a proper package that works along the same lines as 
the wanpipe package.  What we have partially works, but is also 
partially broken.  Rhino Equipment knows this and is working to resolve 
it.  We are making every effort to have this included in 0.4.5, but if 
they are unable to get a working package to us, it may not be included.  
We are very grateful to all of the hardware companies that are working 
with us to have their drivers included (and therefore their hardware 
supported).

I also don't wish to be rude, but you are working on a development 
system.  The final compiled "Astlinux" product works.  It is also mostly 
stable which for a 0.4x version of a program is pretty reasonable.  If 
we were post 1.0, I can understand your complain.  If you've been 
involved in other projects SVN is a dynamic creature.  Sometimes changes 
are submitted which temporarily break things.  When we create the 0.4.5 
tag, we hope to have some of these issues resolved.

Perhaps some of this is my fault.  I had referred to 0.4 branch as 
stable.  Compared to trunk it is stable, but it is still a development 
environment.

Darrick

-- 
Darrick Hartman
DJH Solutions, LLC
http://www.djhsolutions.com