minisip trunk build error

[Cesc]

Hi,

See inline.

On 5/15/06, Zach Welch <zach-minisip at splitstring.com> wrote:
> Cesc wrote:
> > On 5/14/06, Zach Welch <zach-minisip at splitstring.com> wrote:
> >> Great detective work; it looks like we require libtool >= 1.5.7. I have
> >> just added a new document (README.deps in r2503) to explain this issue.
> >>
> >> Over time, we will expand that document to include additional tools, and
> >> further quantify the minimum/tested versions (and their related quirks).
> >>
> > Hi Zach,
> >
> > I hate to say it ... but i think that this is unacceptable. Minisip
> > was perfectly buildable in such an environment (which is the default
> > in Debian stable ... which is not going to change in the coming future
> > and to which some of us like to stick due to its reliability), thus i
> > don't think we can simply say "it won't compile there anymore, sorry".
>
> Okay, so either use the patch that Troy pointed out, or use symlinks.
> This is a bug in *libtool*, and *not* in our code. We absolutely should
> not work around it; if anything, you need to complain to the Debian
> libtool package maintainer and get that patch included. Right? Oh,
> wait a sec; it is Debian's processes that are causing actual problem:
> the "stable" tree is simply too old.
>

I repeat, for the last time. During the last few months, the only
thing that changed is minisip ... libtool stayed the same. And minisip
used to compile. Now it doesn't.
And it is not just libtool ... i remind you. Even you work around the
.libs/.libs problem, a whole bunch of other problems persist.


> Besides, this is a development tool; the built packages should still run
> on Debian stable, even if you have to upgrade libtool to do it.
>

I will try to contact the libtool mantainer for debian ...

> > I think we can identify two different problems here:
> > - libltdl
> > - libtool and double .libs
> >
> > The libltdl problem is related to the use of plug-ins ... the libltdl
> > library used to be part of the libmutil folder, now we try to obtain
> > it from an existing system folder. Either we go back to having it in
> > the libmutil dir, or we fix the problem.
>
> Again, this is a bug caused by your distribution failing to include a
> correctly working libtool package; this is not a bug in minisip. In
> fact, trying to go back is likely to break other use cases; there is
> absolutely no way that fixing this is worth my time. If someone else
> tries, I will be grossly annoyed if things are broken in the attempt.
>

Rest assured that i will try to fix it ... and i got just as "grossly
annoyed" as you will do when compilation in debian stable was broken
:D

> Please do not blame my fixes to the codebase just because they have
> exposed bugs in versions of the tools that are years out-of-date.
> If anything, *that* is unacceptable.
>

I do not blame you or your script. If that was the impression in the
mail, i apologize.
The build.pl script beats the crap out of my old buildall.sh stuff,
which was a "patch" to automate the build process described on the
website, no more, no less.

Now, what i do say is that with all the changes in the last few
months, the compilation was broken. My fault is also there for not
trying in an earlier stage and pointing out that compilation was
broken. And, given you and mikael did most of the changes and seem to
be the most literate in this area, i would request you take some time
to fix it. I will put some time also, but i do not "control" so much
the auto-tools stuff.

And if i may point out one inconsistency in the line of thought ...
why the code style needs to stick to the 80 column rule (old
fashioned, really out-of-date editors) when the state of the art is
far ahead? ;)  Even debian stable has better editors :)

> > The libtool stuff ... ok, that we may not have so much control over. I
> > still don't understand why it used to work and suddenly it started
> > doing such a thing. Minisip from december 2005 works fine. Something
> > changed ... we should figure it out. For the time being, at the very
> > least, the build system should pop out an automatic alert telling the
> > "ln -s . .libs" solution to solve the compilation problem ... people
> > tend not to read the README files :D
>
> Well, I'll give you one big clue: people want to use in-tree building
> and not install things. That's just wrong, folks, but I have supported
> your wishes as far as I can. If you want it to work better, you need to
> use versions of the tools that do their job like they are supposed to.
> Otherwise, you should not complain; there are clearly workarounds that
> will allow you to get the job done.
>

in-tree + not install -> buildall.sh
out-of tree such is done by build.pl is perfectly fine by me.
I still don't see where does this come from ... i have no problem with
the build.pl tool per se ... just with the broken compilation on a
perfectly valid platform (the stable debian is simply one year old ...
it is not like i am trying to compile on minix or something like
that).


> There is not a real problem here.  Troy, what is your opinion on this?

There is a problem ... it may not be real because you don't use that
platform. But it is veery real to me.

>
> Cheers,
>
> Zach
>

Regards,

Cesc