[OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared

[Marcin Cieslak]

Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Fri, Mar 12, 2010 at 12:01:53PM +0000, Marcin Cieslak wrote:
>> However, regardless of the --enable-shared, the build process
>> creates only static libotr.a library, and no DLL.
>> In fact, the error message on the way is:
>
> This is the configure line I use to build it:
>
> ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \
>         --prefix=/usr/i586-mingw32msvc

I don't use MSVC, only gcc, so my host is "i686-pc-mingw32".
Other than that - this does not help, I also get the warning
using --with-pic and --build as well. The build completes
with the static library only.

> The suspicious thing here is that I'm pretty sure there shouldn't *be*
> any undefined symbols.  Can you see what "U" lines nm outputs?

There are none (checked). Libtool complains "just in case" and does
not check for the actual presence of the unknown symbols. 
"-no-undefined" used to be the default in the days of yore,
so it might have never been the problem in the past. 

So another question: do you remember a proper sequence of
autoconf/automake/aclocal/whatever to regenerate ./configure
and the Makefiles?

I have tried something and it works only partially (i.e. I still
don't get shared libraries AND I had to patch ./libtool by hand
because "$echo" was undefined ("$ECHO" was defined).  This might
have something to do with the new version of libtool.

Anway, I have:

autoconf (GNU Autoconf) 2.63
automake (GNU automake) 1.11
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365 2005/12/18 22:14:06
)

Both libgcrypt and libgpg-error have the magic AC_LIBTOOL_WIN32_DLL
(as well as AC_LIBTOOL_RC) before AM_PROG_LIBTOOL, so I felt
like I might want to include that as well.

> PS: This should probably be on otr-dev, not otr-users.  But whatever.  ;-)

I am a newbie, so ... :)

-- 
              << Marcin Cieslak // saper at saper.info >>