[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Trying to compile Epic



On Sat, Sep 30, 2000 at 08:40:53PM +0000, Frederico S. Muñoz wrote:
> 
> Hello all,
> 
> I'm trying to compile Epic (partly because I think that GNU/Hurd would
> benefict from having an IRC client, and I'm partial to Epic - instead
> of BitchX, for example, altough I would really like to have a non-X
> IRC client that was GPLed).
> Two issues arised:
> 
> 1: The MAXPATHLEN/PATHMAX issue; I would really like if you guys could
> give me further issue on this one (begining in what the hell does it
> defines... I have some guesses, but...); by context I see that it is
> used to allocate mem trough malloc and friends, based on some system
> specific value. What's the best way to handle this one? I have been
> substituting it with some value (30 for tree, used 4000 for epic based
> on info given in this list).
> 
> 2: It compiles, but when run it gives a general protection error
> (wind_index = -1 I think); this one I really can't understand, altough
> I will try to look at the source to see what does it refer to.
> 
> Any general advice for compiling issues would be appreciated (BTW I'm
> doing a native Hurd compile).
> 
> Best Regards,
> 
> Frederico Muñoz

Actually, at some point I've already gotten EPIC to compile under the Hurd.
I don't have the changes anymore since it wasn't for myself but for
someone who asked me for help on IRC. But I remember that the MAXPATHLEN
issues. I didn't solve them properly since I only #defined it to be 4096 like
in linux. A better way to handle it would be to use arbitrary length
string operations provided by glibc. If you want an example check out my
pmake patch at http://alcor.concordia.ca/~i_khavki/. The other issue was
that EPIC tries to allocate an array of the size of the order of the
maximum number of file descriptors on the system (you can query sysinfo(2)
for that), on Hurd the number that you get is either INT_MAX or -1, so that's
where the crash comes from. I didn't fix it properly either, just replaced
it by some arbitrary large number.

Both of these problems are not strictly bugs (except under the Hurd)
but more design decisions. So you have to dig around the code a bit,
to see how you could fix it properly.

Igor




Reply to: