Finch and console ui

[Ethan Blanton]

Bill Fassler spake unto us the following wisdom:
> As always I appreciate your input Josh.  I also think there are things
> horribly broken in the pidgin/finch automake, autoconf, and libtool
> environment especially with regards to static builds.  I am a decent
> software engineer, but I am so new to open source and linux that I am
> floundering a little and I don't understand the recursive automagic
> smoke and mirrors.  I was hoping for a little more help from the core
> developers, but they seem to have their hands full and are not overly
> concerned with my "off the beaten path" endeavors.

I have several things to say in response to this.

One, I have not seen anything in this exchange to lead be to believe
that *anything* is "horribly broken".  At the very worst, there are
some conditions which are not accounted for in autotools, and it
sounds like they are probably either quite simple things, or
limitations in the build environment -- in either case, this is
*exactly* what autotools are here to solve, and our configure script
simply needs to be extended to handle it, if anything.  That is the
nature of cross-platform builds; sometimes a new platform requires
tweaks.  None of the autotools maintainers, the library maintainers
for libraries which may have insufficient detection scripts, nor the
Pidgin developers can be expected to have thought of everything.  It
is in the nature of first-time ports that you will have to isolate and
solve problems like this.

Two, not only have a few "core developers" replied to various points
in this thread, but Josh has been providing you with excellent advice
and help.  I do not think you should consider it "second class" simply
because it is not coming from someone listed in the about box -- I
could not have provided better assistance, myself.

As far as buy-in from my part, don't take this the wrong way, but I
have not gotten involved because, to me, it looks like many of your
problems have come from having an incorrectly or incompletely
configured cross-compilation environment.  I, and possibly other
Pidgin developers, simply don't have time to work through getting the
basic, non-project-specific things working -- I think everyone can
agree that Pidgin developer time is best spent developing Pidgin, not
figuring out how to get gcc and the linker working for an embedded
environment.  I apologize if I have misapprehended the situation.

> I have decided to fall back and punt and see if things go better if I
> build dynamically linked versions. Maybe I'll learn something in the
> process, but even it works it would be unacceptable because libraries
> such as gettext, glib, and xml2 are way too huge to include in an
> embedded product just so one application can use "parts" of them.

If you are targeting an environment where glib, particularly, is too
large, then I think you've chosen the wrong product.  That aside,
removing gettext entirely (assuming you do not need localization
support) is certainly possible, it just isn't something that we have
found a need to prioritize.  This used to be simple (pass
--disable-nls to configure), but intltool broke that support.  We
would certainly welcome a clean solution to disabling gettext at
compile time, as it has been requested before.  As far as libxml2,
Pidgin uses XML for various internal configuration files, as well as
for the XMPP and bonjour plugins; all of this is via an internal XML
parsing abstraction, xmlnode.  If you find libxml2 unsatisfactory for
your needs, you can probably replace the existing xmlnode
implementation with one which uses a lighter parsing engine.  We
previously used gmarkup, but it proved insufficient for some reason (I
forget why, exactly).

Somewhere in one of these emails, you were talking about linking
order; again, this comes back to simple development knowledge, not
Pidgin-specific topics, but in *any* compilation environment, symbol
dependencies should proceed from left to right on the compiler command
line.  (That is, an object which requires a symbol must occur to the
left of the object which provides the symbol.)  It sounds to me like
libpanel simply requires libncurses, and they have been compiled in
such a way that the linker cannot infer this in your environment; this
would indeed cause -lpanel to have to occur to the left of -lncurses.
Try changing the line in configure.ac which says AC_CHECK_LIB(panel,
...) to:

AC_CHECK_LIB(panelw, update_panels, [GNT_LIBS="$GNT_LIBS -lpanel],
             [enable_consoleui=no], [-lncurses])

... then rerun autogen.sh, and see if configure succeeds.  If it does,
then this is precisely the problem.  You may then have to change the
way the GNT_LIBS variable is built to fix the actual compile, but one
step at a time.

I hope that satisfies your concern about our concern.  :-P

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070906/88b2d1c9/attachment.sig>