SDL_gfx Library Compilation libtool warning message and cannot build shared libraries

[Canberk Sönmez]

I originally asked this question on stackoverflow. Some of them recommended
me that I ask it on this address, since it looks very libtool specific.
I actually solved my problem by downloading pre-built binaries but I ask to
you since maybe there is a bug or something.
My original question

Here is my question I simply made copy and paste:

I am using MinGW 4.8.1. I have downloaded SDL 2.0.3 development files
archive for Windows. It contains 64-bit and 32-bit development files for
Mingw in i686-w64-mingw32 and x86_64-w64-mingw32 and MSVC development files
in root directory. I have extracted the archive to
C:\SourceCode\Libraries\SDL2-2.0.3 directory. When I want to use SDL, I
simply add C:\SourceCode\Libraries\SDL2-2.0.3\i686-w64-mingw32\include to
Include Directories and
C:\SourceCode\Libraries\SDL2-2.0.3\i686-w64-mingw32\libto Library Paths.
Then I link the mingw32, SDL2main and SDL2 libraries. This way, I can
successfully compile SDL programs. But there is a problem when compiling a
library using SDL. I tried to compile SDL2_gfx library. It does not have
windows specific build option for MinGW. So you have use MSYS to compile
it. I have used following configuration flags for compiling with MSYS:

../configure --prefix="/c/SourceCode/Source/SDL2_gfx-1.0.1/prefix"
--with-sdl-prefix="/c/SourceCode/Libraries/SDL2-2.0.3/i686-w64-mingw32/"

I used --prefix option for isolating installed files from my MSYS
directory. Since MSYS cannot know where the SDL is I used --with-sdl-prefix.

The configuration had done successfully. Then, I execute make command.
After a list of compilation processes, the linker process has warned me
with:

libtool: link: warning: library
`/c/SourceCode/Libraries/SDL2-2.0.3/i686-w64-mingw32/lib/libSDL2.la'
was moved.

*** Warning: linker path does not have real file for library -lmingw32.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libmingw32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: c:/mingw/lib/libmingw32.a

*** Warning: linker path does not have real file for library -lSDL2main.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libSDL2main and none of the candidates passed a file format test
*** using a file magic. Last file checked:
/c/SourceCode/Libraries/SDL2-2.0.3/i686-w64-mingw32/lib/libSDL2main.a

*** Warning: linker path does not have real file for library -ldxguid.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdxguid and none of the candidates passed a file format test
*** using a file magic. Last file checked: c:/mingw/lib/libdxguid.a

*** Warning: linker path does not have real file for library -ldxerr8.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdxerr8 and none of the candidates passed a file format test
*** using a file magic. Last file checked: c:/mingw/lib/libdxerr8.a

*** Warning: linker path does not have real file for library -luuid.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: c:/mingw/lib/libuuid.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Then I only had a static library. At first I ignored these warnings and
kept using static library in my project.

When I use the static version of that library I encountered a lot of
unresolved functions errors in ldoutput. They are kind of "SDL_XXX" not
found. I

Re: [Autoconf] Re: Libtool warning message

[Pavel Roskin]

Hello, Gary and Bob!

> > checking whether a program can dlopen itself... cat: cannot open conftest.cc
> > no
> 
> This looks like a problem in AC_TRY_RUN from cvs autoconf to me.  Are

Words "dlopen itself" come from ltconfig.in. If you look around those
words, you will find an excellent example of a wrong assumption:

cat > conftest.c < conftest.c < conftest.$ac_ext < conftest.c < conftest.$ac_ext < To be sure, could you try it again with autoconf-2.13 and see whether
> it goes away, please?

Yes, it does. Which means that ltconfig is run with the C language active
when Autoconf-2.13 is used. For Autoconf-2.49a the current language is
C++. I tried this on libtool itself.

I don't know what language should be active when ltconfig is run. However,
if you search for "sco3.2v5" in libtool.m4 you will find an explicit
AC_LANG_C in AC_LIBTOOL_SETUP, which _probably_ means that running
ltconfig in the C++ mode is not ruled out.

Otherwise, you need a check in ltconfig.in that the current language is C
and nothing else. You may also need to use AC_LANG_C not only for
"sco3.2v5"

Regards,
Pavel Roskin

Re: Libtool warning message

[Gary V. Vaughan]

On Sat, Sep 16, 2000 at 03:55:21PM -0500, Bob Friesenhahn wrote:
> Using CVS Automake, Autoconf, and multi-lingual libtool I see the
> following message printed from configure:
> 
> checking whether a program can dlopen itself... cat: cannot open conftest.cc
> no
> 
> Under Solaris 2.6.
> 
> I believe that the main-branch libtool prints the same message.

This looks like a problem in AC_TRY_RUN from cvs autoconf to me.  Are
you using the CXX tag?  If so my guess is that AC_TRY_RUN gets
confused about the extension to use for the test file it wants to
compile...

To be sure, could you try it again with autoconf-2.13 and see whether
it goes away, please?

Cheers,
Gary.
-- 
  ___  _   ___   __  _ mailto: [EMAIL PROTECTED]
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___   [EMAIL PROTECTED] 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/  /___/  gpg public key:
http://www.oranda.demon.co.uk   http://www.oranda.demon.co.uk/key.asc

Libtool warning message

[Bob Friesenhahn]

Using CVS Automake, Autoconf, and multi-lingual libtool I see the
following message printed from configure:

checking whether a program can dlopen itself... cat: cannot open conftest.cc
no

Under Solaris 2.6.

I believe that the main-branch libtool prints the same message.

Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen