Finch and console ui

Bill Fassler bill.fassler at yahoo.com
Thu Sep 6 18:02:29 EDT 2007


Thanks Ethan.  

I have good news and bad news.  Your advice worked to the extent that my enableconsolui was set after tweaking configure.ac, running an autogen.sh script and then my configure script.  However, my make no longer worked and I couldn't build anything.  Here's the rest of the story:

I went out and did what I should have done a couple months back, I bought several books including Sean's book and one on GNU AUTOCONF, AUTOMAKE  and LIBTOOL  Your suggested solution towards the end of your note was not intuitive to me, but now makes sense and I think it may work if I can figure out the rest.  My first attempt set the console ui (yipee) but broke my makefile (ugh).

Does pidgin/finch have a specific autogen.sh?  I don't see it in my source.  I don't have one in my /bin/sh directory either. I did locate one on the Internet and hopefully it is generic. Here it is:
*****************************************************
#!/bin/sh
autoreconf --force --install
intltoolize --force --copy --automake
******************************************************
But when I ran it I got these warnings/errors:
*****************************************************
vocal at Grumpy:~/project/blackfin-svn-branch/elf_flat/uClinux-dist/user/pidgin-2.0.0$ ./autogen.sh 
/usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG
/usr/share/aclocal/smpeg.m4:13:   run info '(automake)Extending aclocal'
/usr/share/aclocal/smpeg.m4:13:   or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG
/usr/share/aclocal/smpeg.m4:13:   run info '(automake)Extending aclocal'
/usr/share/aclocal/smpeg.m4:13:   or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.ac:109: error: possibly undefined macro: AC_PROG_INTLTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
./autogen.sh: 3: intltoolize: not found
***************************************************************
I decided to just run my configure script anyway:
***************************************************************
#!/bin/sh
./configure --prefix=/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr --disable-dbus --disable-gtkui --disable-sm --disable-doxygen 
--disable-screensaver --without-x  --host=bfin-uclinux --disable-pcre --disable-gstreamer --disable-gtkspell --disable-gevolution  --disable-fortify --disabl
e-tcl --disable-plugins --with-dynamic-prpls=gg,irc,msn,novell,oscar,qq,simple,yahoo,zephyr --enable-nss=no --disable-gnutls  --with-screen=ncurses --with-nc
urses-headers=/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/include LDFLAGS="-lpthread -L/home/vocal/project/blackfin-svn-branch/
elf_flat/uClinux-dist/staging/usr/lib#!/bin/sh
./configure --prefix=/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr --disable-dbus --disable-gtkui --disable-sm --disable-doxygen 
--disable-screensaver --without-x  --host=bfin-uclinux --disable-pcre --disable-gstreamer --disable-gtkspell --disable-gevolution  --disable-fortify --disabl
e-tcl --disable-plugins --with-dynamic-prpls=gg,irc,msn,novell,oscar,qq,simple,yahoo,zephyr --enable-nss=no --disable-gnutls  --with-screen=ncurses --with-nc
urses-headers=/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/include LDFLAGS="-lpthread -L/home/vocal/project/blackfin-svn-branch/
elf_flat/uClinux-dist/staging/usr/lib -Wl,-rpath-link=/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/lib" CFLAGS="-D__linux__ -DNO
MMU -I/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/include" CXXFLAGS="-D__linux__ -DNOMMU -I/home/vocal/project/blackfin-svn-bra
nch/elf_flat/uClinux-dist/staging/usr/include" CPPFLAGS="-D__linux__ -DNOMMU -I/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/incl
ude"
 -Wl,-rpath-link=/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/lib" CFLAGS="-D__linux__ -DNO
MMU -I/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/include" CXXFLAGS="-D__linux__ -DNOMMU -I/home/vocal/project/blackfin-svn-bra
nch/elf_flat/uClinux-dist/staging/usr/include" CPPFLAGS="-D__linux__ -DNOMMU -I/home/vocal/project/blackfin-svn-branch/elf_flat/uClinux-dist/staging/usr/incl
ude"
**********************************************************8
and lo and behold I get a console ui enabled.
***********************************************************
pidgin 2.0.0

Build GTK+ 2.x UI............. : no
Build console UI.............. : yes

***********************************************************
Although excited at this point, I typed make and got this:
************************************************************
configure complete, now type 'make'

vocal at Grumpy:~/project/blackfin-svn-branch/elf_flat/uClinux-dist/user/pidgin-2.0.0$ make
Makefile:947: *** missing separator.  Stop.

I know I am being annoying at times, but if you or anyone else recognize these symptoms or if it is a simple case of I need your specific autogen.sh please fill me in.

Regards,
Bill
Ethan Blanton <elb at pidgin.im> wrote: 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
_______________________________________________
Devel mailing list
Devel at pidgin.im
http://pidgin.im/cgi-bin/mailman/listinfo/devel


       
---------------------------------
Boardwalk for $500? In 2007? Ha! 
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20070906/ba02a319/attachment.html>


More information about the Devel mailing list