Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Panicz Maciej Godek 
2013/11/8 Peter Rosin 

> On 2013-11-08 12:18, Panicz Maciej Godek wrote:
> > 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>>
> >
> > The SDL library, for some obscure reason, has its own special
>
> take on that and prescribes that you should keep using main()
>


> > even if you are doing a GUI app. I think the SDLmain library
>
> contains the real WinMain@16 entry point and that entry point
>
> in turn calls the application main function. Or I should perhaps
> > say SDL_main (see that -Dmain=SDL_main define above).
>
> Some part of this fragile SDL crap fails. I don't know what.
> >
> > Perhaps the SDL_main library was compiled to expect an
>
> ordinary main entry point instead of the GUI WinMain@16 version?
> >
> > Just to be clear, I'm not an SDL user. This is just my
>
> understanding of this.
> > The above description might very well be flawed in some way, but SDL
> > initialization is peculiar.
> >
> >
> > I can later try to add some of the options from the libtool
>
> invocation generated by autoconf to my invocation of gcc to see
>
> which particular option causes the failure and then let you know.
>
> I think that your description of the way SDL does things on mingw
>
> is sound (and I think that the goal is to ensure portability, as
> > unix programmers have no idea what the WinMain is)
>
> Hmmm, I have this hunch that the -nostdlib option that libtool adds to the
> g++ invocation beats -mwindows, just like it beats -pthread. But I don't
> know that for a fact...


I just made the following test: I removed the mediation of libtool
and called g++ directly, with the same flags, i.e.
g++ -D_GNU_SOURCE=1 -Dmain=SDL_main -Ic:/mingw/msys/1.0/include/SDL
-Ic:/mingw/msys/1.0/include/guile/2.0 -I/usr/local/include
-Ic:/mingw/msys/1.0/include-Wall -Werror  -g -O2   -o slayer.exe file.o
font.o image.o input.o slayer.o symbols.o video.o   -mwindows
-Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL   -Lc:/mingw/msys/1.0/lib
-lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image
-lmingw32 -lSDLmain -lSDL   -lSDL_ttf

(the initial part, "/bin/sh ../libtool --tag=CXX   --mode=link", was
removed)
and it got linked with no complaints. I then removed both -mwindows flags
from the above invocation, and it did work as well.

So plainly it looks as if there was some problem with libtool on MinGW.
Unfortunately, I'm not a shell scripting master, so I can't say exactly
which command libtool uses to link the program and how it is invoked.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: g++ and -nostdlib

2013-11-08 Thread Bob Friesenhahn 

On Fri, 8 Nov 2013, Peter Rosin wrote:


Hi!

There seem to be a longstanding complaint that libtool is using
-nostdlib when it links libraries using g++. It interferes with
-pthread and I think I have also seen other issues. No one can
give a satisfactory explanation why libtool does this, it seems


Isn't it because libtool wants to control the order of the linking and 
assure that all dependencies (including static) are tracked/known and 
applied at the correct times?  It wants to assure that static 
dependencies are linked into the dependent program rather than into 
some dependent shared library (and thus causing a problem).


It was common (and perhaps still is) for the GNU C++ library to be 
delivered as a static library for Windows/MinGW because C++ exceptions 
were not handled properly when thrown by DLLs.


Quite a lot of effort went into making this work the way it currently 
does.


First libtool tries to take away all of the libraries which would be 
added automatically and then it applies the libraries that GCC says it 
would use at the correct time.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

g++ and -nostdlib

2013-11-08 Thread Peter Rosin 
Hi!

There seem to be a longstanding complaint that libtool is using
-nostdlib when it links libraries using g++. It interferes with
-pthread and I think I have also seen other issues. No one can
give a satisfactory explanation why libtool does this, it seems
like it is just the way it has always been and noone dares
changing it. To me, it all smells like something that was needed
once upon a time when g++ was still immature, and whatever issues
it solved we no longer need to worry about. So, just for thrills
I had a quick peek at the code, and it looks quite simple to
simply nix this obnoxious -nostdlib use.

I realize that the timing isn't the best with the alpha release
and all, but this probably needs to be tested a bit more before
it's pushed anyway, so I'm simply posting this as an RFC and
don't expect it to be committed until later.

Should it be listed as an incompatible change? Or simply a bug
fix?

BTW, it even appears to work, but please test, as I have only
done very light testing...

Oh well. Any thoughts?

Cheers,
Peter
>From a233b4562d4274053852bc0353e36931beeb4803 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Fri, 8 Nov 2013 19:01:24 +0100
Subject: [PATCH] libtool: Do not use -nostdlib when linking with g++.

Fixes part of bug#15646 and Debian bug 468555.

* m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [g++] 
: Drop -nostdlib, $predep_objects and
$postdep_objects.
* NEWS: Update.
---
 NEWS  |6 ++
 m4/libtool.m4 |   30 +++---
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index 0c85812..5717385 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Important incompatible changes:
+
+  - When linking shared libraries with g++, trust the compiler driver to
+interface correctly with the linker.  I.e., drop the -nostdlib
+option in this case. Fixes point 2 (and perhaps 3) in bug#15646, as
+well as Debian bug 468555.
 
 * Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha]
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc6b22..d13afc3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6046,8 +6046,8 @@ if test yes != "$_lt_caught_CXX_error"; then
   # Check if GNU C++ uses GNU ld as the underlying linker, since the
   # archiving commands below assume that GNU ld is being used.
   if test yes = "$with_gnu_ld"; then
-_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname -o $lib'
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared $libobjs $deplibs $compiler_flags $wl-soname $wl$soname -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared $libobjs $deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
 
 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath $wl$libdir'
 _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl--export-dynamic'
@@ -6073,7 +6073,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 # linker, instead of GNU ld.  If possible, this setting should
 # overridden to take advantage of the native linker features on
 # the platform it is being used on.
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $lib'
   fi
 
   # Commands to make compiler produce verbose output that lists
@@ -6296,7 +6296,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 	  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
 
 	  if $LD --help 2>&1 | $GREP 'auto-import' > /dev/null; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
 	# If the export-symbols file already is a .def file, use it as
 	# is; otherwise, prepend EXPORTS...
 	_LT_TAGVAR(archive_expsym_cmds, $1)='if _LT_DLL_DEF_P([$export_symbols]); then
@@ -6305,7 +6305,7 @@ if test yes != "$_lt_caught_CXX_error"; then
   echo EXPORTS > $output_objdir/$soname.def;
   cat $export_symbols >> $output_objdir/$soname.def;
 fi~
-$CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $comp

Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Peter Rosin 
On 2013-11-08 14:15, Peter Rosin wrote:
> On 2013-11-08 12:18, Panicz Maciej Godek wrote:
>> 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>>
>>
>> The SDL library, for some obscure reason, has its own special take on 
>> that and
>> prescribes that you should keep using main() even if you are doing a GUI 
>> app.
>> I think the SDLmain library contains the real WinMain@16 entry point and 
>> that
>> entry point in turn calls the application main function. Or I should 
>> perhaps
>> say SDL_main (see that -Dmain=SDL_main define above). Some part of this
>> fragile SDL crap fails. I don't know what.
>>
>> Perhaps the SDL_main library was compiled to expect an ordinary main 
>> entry
>> point instead of the GUI WinMain@16 version?
>>
>> Just to be clear, I'm not an SDL user. This is just my understanding of 
>> this.
>> The above description might very well be flawed in some way, but SDL
>> initialization is peculiar.
>>
>>
>> I can later try to add some of the options from the libtool invocation 
>> generated
>> by autoconf to my invocation of gcc to see which particular option causes the
>> failure and then let you know. I think that your description of the way SDL 
>> does
>> things on mingw is sound (and I think that the goal is to ensure 
>> portability, as
>> unix programmers have no idea what the WinMain is)
> 
> Hmmm, I have this hunch that the -nostdlib option that libtool adds to the
> g++ invocation beats -mwindows, just like it beats -pthread. But I don't
> know that for a fact...

No, wait. You're not building a library, so -nostdlib isn't relevant...

Sorry for the wasted bandwidth.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Peter Rosin 
On 2013-11-08 12:18, Panicz Maciej Godek wrote:
> 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>>
> 
> The SDL library, for some obscure reason, has its own special take on 
> that and
> prescribes that you should keep using main() even if you are doing a GUI 
> app.
> I think the SDLmain library contains the real WinMain@16 entry point and 
> that
> entry point in turn calls the application main function. Or I should 
> perhaps
> say SDL_main (see that -Dmain=SDL_main define above). Some part of this
> fragile SDL crap fails. I don't know what.
> 
> Perhaps the SDL_main library was compiled to expect an ordinary main entry
> point instead of the GUI WinMain@16 version?
> 
> Just to be clear, I'm not an SDL user. This is just my understanding of 
> this.
> The above description might very well be flawed in some way, but SDL
> initialization is peculiar.
> 
> 
> I can later try to add some of the options from the libtool invocation 
> generated
> by autoconf to my invocation of gcc to see which particular option causes the
> failure and then let you know. I think that your description of the way SDL 
> does
> things on mingw is sound (and I think that the goal is to ensure portability, 
> as
> unix programmers have no idea what the WinMain is)

Hmmm, I have this hunch that the -nostdlib option that libtool adds to the
g++ invocation beats -mwindows, just like it beats -pthread. But I don't
know that for a fact...

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Panicz Maciej Godek 
2013/11/8 Peter Rosin 

> The SDL library, for some obscure reason, has its own special take on that
> and
> prescribes that you should keep using main() even if you are doing a GUI
> app.
> I think the SDLmain library contains the real WinMain@16 entry point and
> that
> entry point in turn calls the application main function. Or I should
> perhaps
> say SDL_main (see that -Dmain=SDL_main define above). Some part of this
> fragile SDL crap fails. I don't know what.
>
> Perhaps the SDL_main library was compiled to expect an ordinary main entry
> point instead of the GUI WinMain@16 version?
>
> Just to be clear, I'm not an SDL user. This is just my understanding of
> this.
> The above description might very well be flawed in some way, but SDL
> initialization is peculiar.
>
>
I can later try to add some of the options from the libtool invocation
generated
by autoconf to my invocation of gcc to see which particular option causes
the
failure and then let you know. I think that your description of the way SDL
does
things on mingw is sound (and I think that the goal is to ensure
portability, as
unix programmers have no idea what the WinMain is)

Regards.
M.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Panicz Maciej Godek 
2013/11/8 Václav Zeman 

> The -mwindows switch says that your are compiling a Windows GUI
> application, which implies WinMain() function. If you are not doing that,
> remove the switch and (maybe) use -mconsole instead. See
> http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Windows-Options.html for
> explanations of the switches.
>

I think the issue can rather be concerned with the use of SDL.
As I mentioned above, when I link using
gcc -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o
-mwindows -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lguile-2.0
the linkage succeeds.
Note that, although the -D option shouldn't have any influence on the
linkage,
it does replace main with SDL_main during the compilation of object files,
and I think it's the SDL_main library that contains the actual entry point.

However, the question is not how to get the things built (because I already
managed to do so), but how to adjust the build system (i.e. configure.acand/or
various Makefile.am files) so that it builds the things properly. In
particular,
I didn't put the -mwindows there in the first place, so I have no option to
remove
it or replace it.

regards,
M.
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Peter Rosin 
On 2013-11-08 11:31, Václav Zeman wrote:
> On 7 November 2013 22:00, Panicz Maciej Godek  > wrote:
> 
> Hi,
> For some time I've been trying to compile my framework
> for writing multimedia and 3d games in Guile Scheme
> on Windows/MinGW.
> The framework uses SDL library, and more details can be
> found here: https://puszcza.gnu.org.ua/projects/slayer
> 
> After many issues with compiling Guile Scheme on MinGW,
> I've finally managed to achieve it, and having build SDL,
> I proceeded to compile my framework.
> 
> Although I did use the autotools to create a package,
> I know only superficially how it is supposed to work.
> Having ./configured my project, I managed to build the
> object files, but the final linking (performed by libtool)
> fails. It is invoked in the following way:
> 
> ./libtool --tag=CXX   --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main 
> -Ic:/mingw/msys/1.0/include/SDL   -Ic:/mingw/msys/1.0/include/guile/2.0 
> -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows 
> -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL   -Lc:/mingw/msys/1.0/lib 
> -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 
> -lSDLmain -lSDL   -g -O2 -mwindows -Lc:/mingw/msys/1.0/lib -lmingw32 
> -lSDLmain -lSDL   -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc -mwindows 
> -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL-o 
> slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o
> -lSDL_ttf 
> 
> and the following error appears:
> c:/mingw/msys/1.0/lib/libmingw32.a(main.o): In function `main':
> 
> e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91:
>  undefined reference to `WinMain@16'
> collect2.exe: error: ld returned 1 exit status
> 
> The -mwindows switch says that your are compiling a Windows GUI application, 
> which implies WinMain() function. If you are not doing that, remove the 
> switch and (maybe) use -mconsole instead. See 
> http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Windows-Options.html 
> for explanations of the switches.

The SDL library, for some obscure reason, has its own special take on that and
prescribes that you should keep using main() even if you are doing a GUI app.
I think the SDLmain library contains the real WinMain@16 entry point and that
entry point in turn calls the application main function. Or I should perhaps
say SDL_main (see that -Dmain=SDL_main define above). Some part of this
fragile SDL crap fails. I don't know what.

Perhaps the SDL_main library was compiled to expect an ordinary main entry
point instead of the GUI WinMain@16 version?

Just to be clear, I'm not an SDL user. This is just my understanding of this.
The above description might very well be flawed in some way, but SDL
initialization is peculiar.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Using libtool via autotools causes linking problem on mingw

2013-11-08 Thread Václav Zeman 
On 7 November 2013 22:00, Panicz Maciej Godek wrote:

> Hi,
> For some time I've been trying to compile my framework
> for writing multimedia and 3d games in Guile Scheme
> on Windows/MinGW.
> The framework uses SDL library, and more details can be
> found here: https://puszcza.gnu.org.ua/projects/slayer
>
> After many issues with compiling Guile Scheme on MinGW,
> I've finally managed to achieve it, and having build SDL,
> I proceeded to compile my framework.
>
> Although I did use the autotools to create a package,
> I know only superficially how it is supposed to work.
> Having ./configured my project, I managed to build the
> object files, but the final linking (performed by libtool)
> fails. It is invoked in the following way:
>
> ./libtool --tag=CXX   --mode=link g++ -D_GNU_SOURCE=1 -Dmain=SDL_main
> -Ic:/mingw/msys/1.0/include/SDL   -Ic:/mingw/msys/1.0/include/guile/2.0
> -I/usr/local/include -Ic:/mingw/msys/1.0/include-Wall -Werror -mwindows
> -Lc:/mingw/msys/1.0/lib -lmingw32 -lSDLmain -lSDL   -Lc:/mingw/msys/1.0/lib
> -lguile-2.0 -lgc -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image
> -lmingw32 -lSDLmain -lSDL   -g -O2 -mwindows -Lc:/mingw/msys/1.0/lib
> -lmingw32 -lSDLmain -lSDL   -Lc:/mingw/msys/1.0/lib -lguile-2.0 -lgc
> -mwindows -Lc:/mingw/msys/1.0/lib -lSDL_image -lmingw32 -lSDLmain -lSDL
>  -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o
>  -lSDL_ttf
>
> and the following error appears:
> c:/mingw/msys/1.0/lib/libmingw32.a(main.o): In function `main':
> e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91:
> undefined reference to `WinMain@16'
> collect2.exe: error: ld returned 1 exit status
>
The -mwindows switch says that your are compiling a Windows GUI
application, which implies WinMain() function. If you are not doing that,
remove the switch and (maybe) use -mconsole instead. See
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Windows-Options.html for
explanations of the switches.


>
> However, I do manage to build the executable with the following command:
> gcc -o slayer.exe file.o font.o image.o input.o slayer.o symbols.o video.o
> -mwindows -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lguile-2.0
>
> (there are still some problems caused by libguile in the runtime, but at
> least the linkign stage succeeds)
>
> I know that it might be a complicated issue, and the cause might lie on
> the side of either MinGW or SDL or pkg-config or autotools or mine, but I
> thought it might be best to ask you first.
>
> The project's files can be browsed here
> http://hg.gnu.org.ua/hgweb/slayer/file/bb4c97fd8329
>
> Thanks in advance,
> M.
>

-- 
VZ
___
https://lists.gnu.org/mailman/listinfo/libtool