Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Wed, Aug 11, 2021 at 3:44 PM Alexei Podtelezhnikov wrote: > > > > >> And as I prefer DLL compared to static lib, I know what to do :-) > > > > I have the distinct impression that static libraries are rarely used under > > Windows any more. > > Perhaps I am off base here. Isn’t this why DLL comes paired with a LIB > wrapper, while static is just LIB. VC links with LIB regardless. Visual Studio uses indeed .lib by default for the import library (what you call the lib wrapper) and for the static library. libtool, meson and cmake (not sure for cmake) are using .dll.a for the import lib Note that having an import lib is not necessary, it's perfectly possible to link against the DLL. The GNU linker allows this. See https://sourceware.org/binutils/docs/ld/WIN32.html, section "direct linking to a DLL" for more information. Vincent Torri
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Wed, Aug 11, 2021 at 3:27 PM Bob Friesenhahn wrote: > > On Wed, 11 Aug 2021, Vincent Torri wrote: > > > > The only solution I can see is : forcing to have only one specific > > library. either static or shared, and throw an error if the wrong lib > > is chosen at configure time. > > > > And as I prefer DLL compared to static lib, I know what to do :-) > > I have the distinct impression that static libraries are rarely used > under Windows any more. > > While useful for debugging, a lot of projects just don't produce them > any more. mupdf was an example of a lib that produced a static lib on Windows and Unix, but in the latest version, they finally added the build of a shared lib Vincent Torri
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Tue, Aug 10, 2021 at 10:38 PM Bob Friesenhahn wrote: > > On Tue, 10 Aug 2021, Vincent Torri wrote: > >> > >> Perhaps better solution is use of -export-symbols. > > > > As I have said, the problem is not the lib itself. There is no problem > > with the lib. The problem is with the binary : when I compile it, > > there is no way to know if the library, that the binary uses, is a > > static library or shared library (know == having a macro to > > distinguish shared lib and static lib) > > This is a good point. For GraphicsMagick we just had to deal with it > and provide an external way to know how the library was expected to > have been compiled. > > This is fragile since it is possible/likely that both static and DLL > are available at the same time and compiler will choose one of them > according to its own rules, and especially if libtool is not used for > linking against that library. I'll for DLL to be chosen thank you Vincent Torri
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Tue, Aug 10, 2021 at 11:19 PM Nick Bowler wrote: > > On 2021-08-10, Vincent Torri wrote: > [...] > > As I have said, the problem is not the lib itself. There is no problem > > with the lib. The problem is with the binary : when I compile it, > > there is no way to know if the library, that the binary uses, is a > > static library or shared library (know == having a macro to > > distinguish shared lib and static lib) > > I'm not too familiar with shared libraries on Windows, but I think > mingw solves this particular problem by generating static wrapper libs > with stub functions that then call the real implementation in the dll. I guess that you are talking about the import library (which could be created with gcc on Windows). Import libraries can also be built with Visual Studio. > With such a wrapper, I suppose there is no difference (from the program's > perspective) between linking against the real static archive versus > linking against the wrapper. When using mingw and libtool simple > libraries appear to "just work" at least. > > Without such a wrapper I suppose you will need to know at compile time > which libraries will be used in the future at link time. I don't think > libtool can make any assumptions here in general, as link options are > not typically passed to compile mode commands (and in fact, many libtool > options are overloaded to mean different things depending on whether you > are running it in compile or link mode). ok, so no perfect solution > It all seems very annoying indeed. I wonder how Windows users deal with > this. Well, if you have a Visual Studio solution (either hand-written, or created with a meta build-system like cmake or meson), you explicitly write the link command. The only solution I can see is : forcing to have only one specific library. either static or shared, and throw an error if the wrong lib is chosen at configure time. And as I prefer DLL compared to static lib, I know what to do :-) thank you Vincent Torri
Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project
On Tue, Aug 10, 2021 at 9:21 PM Roumen Petrov
wrote:
>
> Hi Vincent,
>
> Sorry for top posting.
>
> Perhaps is not easy visible for manual (
> https://www.gnu.org/software/libtool/manual/html_node/Creating-object-files.html
> ) use of conditional code.
> In this case #ifdef PIC.
>
> Perhaps better solution is use of -export-symbols.
As I have said, the problem is not the lib itself. There is no problem
with the lib. The problem is with the binary : when I compile it,
there is no way to know if the library, that the binary uses, is a
static library or shared library (know == having a macro to
distinguish shared lib and static lib)
Vincent
> Vincent Torri wrote:
> > Hello
> >
> > I contribute to an autotools project. The tree is :
> >
> > src/lib/libfoo <--- the library, with libfoo.h declaring the public symbols
> > src/bin/bar <-- the binary which uses libfoo and includes libfoo.h in
> > its source files
> >
> > I want to create the library 'libfoo' on Windows. I also want to
> > declare public symbols with __declspec(dllexport) and
> > __declspec(dllimport) in a macro that I call MY_API in libfoo.h
> >
> > Thanks to DLL_EXPORT that libtool is passing to the preprocessor when
> > compiling the library 'libfoo', there is no problem to compile libfoo.
> > MY_API is correctly defined either when I build the static lib, or the
> > shared lib, or both.
> >
> > The problem I am facing is when I build the 'bar' binary. On Windows:
> >
> > 1) if 'lifoo' is built as a shared library, when I include libfoo.h in
> > 'bar' source files, MY_API must be defined as __declspec(dllimport)
> > 2) if 'libfoo' is built as a static library, when I include libfoo.h
> > in 'bar' source files, MY_API must be defined as nothing
> >
> > but, as far as I know, when I compile 'bar', I couldn't find a way to
> > know if 'libfoo' has been compiled as a static library or as a shared
> > library. I have looked at the 'bar' source files gcc calls, and they
> > are the same in both cases (libfoo compiled as a static or shared
> > lib). So I don't know how I can correctly define my macro MY_API.
> >
> > Here is, for now, my macro:
> >
> > #if defined(_WIN32) || defined(__CYGWIN__)
> > # ifdef FOO_BUILD // defined when building 'libfoo'
> > # ifdef DLL_EXPORT
> > # warning "BUILD DLL"
> > # define MY_API __declspec(dllexport)
> > # else
> > # warning "BUILD STATIC"
> > # define MY_API
> > # endif
> > # else
> > # warning "IMPORT DLL"
> > # define MY_API __declspec(dllimport)
> > # endif
> >
> > in the last #else, I don't know what to do to correctly manage MY_API
> > for my problem above
> >
> > One solution would be : never compile 'lbfoo' as a static lib ("DLL
> > are good on Windows"), but I would like to support both static and
> > shared libraries.
> >
> > Does someone know how to solve my issue ? (I hope I've been clear enough...)
> >
> > thank you
> >
> > Vincent Torri
> >
>
> Regards,
> Roumen Petrov
>
>
Question about static and shared libraries and their usage in a binary on Windows in a autotools project
Hello
I contribute to an autotools project. The tree is :
src/lib/libfoo <--- the library, with libfoo.h declaring the public symbols
src/bin/bar <-- the binary which uses libfoo and includes libfoo.h in
its source files
I want to create the library 'libfoo' on Windows. I also want to
declare public symbols with __declspec(dllexport) and
__declspec(dllimport) in a macro that I call MY_API in libfoo.h
Thanks to DLL_EXPORT that libtool is passing to the preprocessor when
compiling the library 'libfoo', there is no problem to compile libfoo.
MY_API is correctly defined either when I build the static lib, or the
shared lib, or both.
The problem I am facing is when I build the 'bar' binary. On Windows:
1) if 'lifoo' is built as a shared library, when I include libfoo.h in
'bar' source files, MY_API must be defined as __declspec(dllimport)
2) if 'libfoo' is built as a static library, when I include libfoo.h
in 'bar' source files, MY_API must be defined as nothing
but, as far as I know, when I compile 'bar', I couldn't find a way to
know if 'libfoo' has been compiled as a static library or as a shared
library. I have looked at the 'bar' source files gcc calls, and they
are the same in both cases (libfoo compiled as a static or shared
lib). So I don't know how I can correctly define my macro MY_API.
Here is, for now, my macro:
#if defined(_WIN32) || defined(__CYGWIN__)
# ifdef FOO_BUILD // defined when building 'libfoo'
# ifdef DLL_EXPORT
# warning "BUILD DLL"
# define MY_API __declspec(dllexport)
# else
# warning "BUILD STATIC"
# define MY_API
# endif
# else
# warning "IMPORT DLL"
# define MY_API __declspec(dllimport)
# endif
in the last #else, I don't know what to do to correctly manage MY_API
for my problem above
One solution would be : never compile 'lbfoo' as a static lib ("DLL
are good on Windows"), but I would like to support both static and
shared libraries.
Does someone know how to solve my issue ? (I hope I've been clear enough...)
thank you
Vincent Torri
pass compiler flags only when static library is built
Hello I have a project which uses the autotools as build system (autoconf, + automake + libtool). is it possible to pass to the compiler a flag only when the static library is built ? i have tried to set lt_prog_compiler_static in configure.ac, with no luck thank you Vincent Torri
ading a make rule to a .la (or another) file
Hello Here is a description of my problem: I have the following files : etui/ Makefile.am (which includes src/modules/pdf/Makefile.mk) src/ modules/ pdf/ Makefile.mk etui_module_pdf.c mupdf-1.10a/ Makefile other mupdf files I my Makefile.mk, I already have : -- etui_modules_pdf_LTLIBRARIES = src/modules/pdf/module.la src_modules_pdf_module_la_SOURCES = \ src/modules/pdf/etui_module_pdf.c \ src/modules/pdf/etui_module_pdf.h src_modules_pdf_module_la_LIBADD = \ src/lib/libetui.la \ -L$(abs_srcdir)/src/modules/pdf/mupdf-1.10a/build/release -lmupdf \ -L$(abs_srcdir)/src/modules/pdf/mupdf-1.10a/build/release -lmupdfthird \ @ETUI_LIBS@ -- But etui_module_pdf.c needs to build mupdf shared library and link against it, that is, just run 'make' in mupdf-1.10a/ So, in my Makefile.mk, I would like to do something like: src/modules/pdf/src_modules_pdf_module_la-etui_module_pdf.lo: buildmupdf buildmupdf: cd src/modules/pdf/mupdf-1.10a && make but 'make' is never called before the link (or compilation) of my module. I have tried to use .la, or .o for the file, without any luck Does someone know what I should add to build mupdf *before* the link of my module ? thank you Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
argument list too long error
hello, In a project i'm following, i've seen that bug report: https://phab.enlightenment.org/T2225 The build system pass a huge number of identical options and libtool does not try to remove them is it a problem with libtool (that is, libtool should indeed remove such identical options) or in the build system (that is, we should optimize the build system so that non identical options are passed) ? thank you Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: argument list too long error
Here is below the list of arguments Vincent Torri libtool: compile: x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../src/lib/efl -DPACKAGE_BIN_DIR=\/opt/windows_64/bin\ -DPACKAGE_LIB_DIR=\/opt/windows_64/lib\ -DPACKAGE_DATA_DIR=\/opt/windows_64/share/ethumb\ -DPACKAGE_BUILD_DIR=\/home/win7-virtualbox/install/efl\ -D__USE_MINGW_ANSI_STDIO -Wall -Wextra -Wpointer-arith -Wno-missing-field-initializers -fvisibility=hidden -fdata-sections -ffunction-sections -I../src/lib/emotion -I../src/lib/emotion -I../src/bindings/emotion -I../src/bindings/emotion -I../src/lib/eio -I../src/lib/eio -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eet -I../src/lib/eet -I../src/lib/emile -I../src/lib/emile -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/ecore -I../src/lib/ecore -I../src/lib/efl -I../src/lib/efl -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/efl -I../src/lib/efl -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/evas -I../src/lib/evas -I../src/lib/emile -I../src/lib/emile -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/efl -I../src/lib/efl -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/eet -I../src/lib/eet -I../src/lib/emile -I../src/lib/emile -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/eet -I../src/lib/eet -I../src/lib/emile -I../src/lib/emile -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/ecore -I../src/lib/ecore -I../src/lib/efl -I../src/lib/efl -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/evil -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -DEFL_EMOTION_BUILD=1 -D__USE_MINGW_ANSI_STDIO -Wall -Wextra -Wpointer-arith -Wno-missing-field-initializers -fvisibility=hidden -fdata-sections -ffunction-sections -I../src/lib/ethumb -I../src/lib/ethumb -I../src/bindings/ethumb -I../src/bindings/ethumb -I../src/lib/edje -I../src/lib/edje -I../src/lib/eio -I../src/lib/eio -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil -I../src/lib/eet
Re: argument list too long error
On Wed, Mar 25, 2015 at 2:06 PM, Vincent Torri vincent.to...@gmail.com wrote: Here is below the list of arguments Vincent Torri libtool: compile: x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../src/lib/efl -DPACKAGE_BIN_DIR=\/opt/windows_64/bin\ -DPACKAGE_LIB_DIR=\/opt/windows_64/lib\ -DPACKAGE_DATA_DIR=\/opt/windows_64/share/ethumb\ -DPACKAGE_BUILD_DIR=\/home/win7-virtualbox/install/efl\ -D__USE_MINGW_ANSI_STDIO -Wall -Wextra -Wpointer-arith -Wno-missing-field-initializers -fvisibility=hidden -fdata-sections -ffunction-sections -I../src/lib/emotion -I../src/lib/emotion -I../src/bindings/emotion -I../src/bindings/emotion -I../src/lib/eio -I../src/lib/eio -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/eo -I../src/lib/eo -I../src/lib/eina -I../src/lib/eina -I../src/lib/evil -I../src/lib/evil -D_REENTRANT -I../src/lib/evil -I../src/lib/evil [snip] also it seems that on Linux, it's not the case (no such long list of arguments), while on Windows, it is. So maybe a problem in the Windows port of libtool Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: argument list too long error
Is this log file sufficient ? Vincent Torri On Wed, Mar 25, 2015 at 8:39 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Wed, 25 Mar 2015, Vincent Torri wrote: also it seems that on Linux, it's not the case (no such long list of arguments), while on Windows, it is. So maybe a problem in the Windows port of libtool The only way to know this is if we could see the arguments which were passed to libtool, but you did not provide this to us. Are the duplicate arguments passed to libtool? Windows has a vastly smaller command line limit than Linux does, and the Windows command-line limit is combined with environment variable space so more environment variables decreases the command-line length limit. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ efl.log Description: Binary data ___ https://lists.gnu.org/mailman/listinfo/libtool
ibtool: install: error: cannot install `foo.la' to a directory not ending in bar/
Hey I have that error with my package. Usually, it's a problem of configuration and prefix. I know that I have solved that problem with a 'make clean', 'make' then 'make install'. But it's not sufficient. First, the commands I run: make maintainer-clean ./autogen.sh --prefix=$HOME/local/e17 make make install Error: test -z /home/torri/local/e17/lib/evas/modules/engines/buffer/ || /bin/mkdir -p /home/torri/local/e17/lib/evas/modules/engines/buffer/ /bin/bash ../libtool --mode=install /usr/bin/install -c modules/evas/engines/buffer/module.la '/home/torri/local/e17/lib/evas/modules/engines/buffer/' libtool: install: error: cannot install `modules/evas/engines/buffer/module.la' to a directory not ending in /home/torri/local/e17/lib/evas/modules/engines/buffer/ make[3]: *** [install-enginebufferpkgLTLIBRARIES] Error 1 In my Makefile.am, the buffer engine is set up like that: if BUILD_ENGINE_BUFFER dist_installed_evasmainheaders_DATA += modules/evas/engines/buffer/Evas_Engine_Buffer.h BUFFER_SOURCES = \ modules/evas/engines/buffer/evas_engine.c \ modules/evas/engines/buffer/evas_outbuf.c \ modules/evas/engines/buffer/evas_engine.h if EVAS_STATIC_BUILD_BUFFER lib_evas_libevas_la_SOURCES += $(BUFFER_SOURCES) else enginebufferpkgdir = $(libdir)/evas/modules/engines/buffer/$(MODULE_ARCH) enginebufferpkg_LTLIBRARIES = modules/evas/engines/buffer/module.la modules_evas_engines_buffer_module_la_SOURCES = $(BUFFER_SOURCES) modules_evas_engines_buffer_module_la_CPPFLAGS = \ -I$(top_srcdir)/src/lib/eina \ -I$(top_srcdir)/src/lib/eo \ -I$(top_srcdir)/src/lib/evas \ -I$(top_srcdir)/src/lib/evas/include \ -I$(top_srcdir)/src/lib/evas/cserve2 \ @EFL_CFLAGS@ \ @EVAS_CFLAGS@ modules_evas_engines_buffer_module_la_LIBADD = lib/evas/libevas.la @EFL_LIBS@ modules_evas_engines_buffer_module_la_LDFLAGS = -no-undefined -module -avoid-version modules_evas_engines_buffer_module_la_LIBTOOLFLAGS = --tag=disable-static endif endif BUILD_ENGINE_BUFFER is true EVAS_STATIC_BUILD_BUFFER is false So the relevant part is just: enginebufferpkgdir = $(libdir)/evas/modules/engines/buffer/$(MODULE_ARCH) enginebufferpkg_LTLIBRARIES = modules/evas/engines/buffer/module.la modules_evas_engines_buffer_module_la_SOURCES = $(BUFFER_SOURCES) modules_evas_engines_buffer_module_la_CPPFLAGS = \ -I$(top_srcdir)/src/lib/eina \ -I$(top_srcdir)/src/lib/eo \ -I$(top_srcdir)/src/lib/evas \ -I$(top_srcdir)/src/lib/evas/include \ -I$(top_srcdir)/src/lib/evas/cserve2 \ @EFL_CFLAGS@ \ @EVAS_CFLAGS@ modules_evas_engines_buffer_module_la_LIBADD = lib/evas/libevas.la @EFL_LIBS@ modules_evas_engines_buffer_module_la_LDFLAGS = -no-undefined -module -avoid-version modules_evas_engines_buffer_module_la_LIBTOOLFLAGS = --tag=disable-static I have looked at the code closely, but i can't see my error Does someone know what the problem is ? thank you Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: ibtool: install: error: cannot install `foo.la' to a directory not ending in bar/
On Sun, Nov 4, 2012 at 11:29 AM, Vincent Torri vincent.to...@gmail.com wrote: Hey I have that error with my package. Usually, it's a problem of configuration and prefix. I know that I have solved that problem with a 'make clean', 'make' then 'make install'. But it's not sufficient. First, the commands I run: make maintainer-clean ./autogen.sh --prefix=$HOME/local/e17 make make install Error: test -z /home/torri/local/e17/lib/evas/modules/engines/buffer/ || /bin/mkdir -p /home/torri/local/e17/lib/evas/modules/engines/buffer/ /bin/bash ../libtool --mode=install /usr/bin/install -c modules/evas/engines/buffer/module.la '/home/torri/local/e17/lib/evas/modules/engines/buffer/' libtool: install: error: cannot install `modules/evas/engines/buffer/module.la' to a directory not ending in /home/torri/local/e17/lib/evas/modules/engines/buffer/ make[3]: *** [install-enginebufferpkgLTLIBRARIES] Error 1 In my Makefile.am, the buffer engine is set up like that: if BUILD_ENGINE_BUFFER dist_installed_evasmainheaders_DATA += modules/evas/engines/buffer/Evas_Engine_Buffer.h BUFFER_SOURCES = \ modules/evas/engines/buffer/evas_engine.c \ modules/evas/engines/buffer/evas_outbuf.c \ modules/evas/engines/buffer/evas_engine.h if EVAS_STATIC_BUILD_BUFFER lib_evas_libevas_la_SOURCES += $(BUFFER_SOURCES) else enginebufferpkgdir = $(libdir)/evas/modules/engines/buffer/$(MODULE_ARCH) enginebufferpkg_LTLIBRARIES = modules/evas/engines/buffer/module.la modules_evas_engines_buffer_module_la_SOURCES = $(BUFFER_SOURCES) modules_evas_engines_buffer_module_la_CPPFLAGS = \ -I$(top_srcdir)/src/lib/eina \ -I$(top_srcdir)/src/lib/eo \ -I$(top_srcdir)/src/lib/evas \ -I$(top_srcdir)/src/lib/evas/include \ -I$(top_srcdir)/src/lib/evas/cserve2 \ @EFL_CFLAGS@ \ @EVAS_CFLAGS@ modules_evas_engines_buffer_module_la_LIBADD = lib/evas/libevas.la @EFL_LIBS@ modules_evas_engines_buffer_module_la_LDFLAGS = -no-undefined -module -avoid-version modules_evas_engines_buffer_module_la_LIBTOOLFLAGS = --tag=disable-static endif endif BUILD_ENGINE_BUFFER is true EVAS_STATIC_BUILD_BUFFER is false So the relevant part is just: enginebufferpkgdir = $(libdir)/evas/modules/engines/buffer/$(MODULE_ARCH) enginebufferpkg_LTLIBRARIES = modules/evas/engines/buffer/module.la modules_evas_engines_buffer_module_la_SOURCES = $(BUFFER_SOURCES) modules_evas_engines_buffer_module_la_CPPFLAGS = \ -I$(top_srcdir)/src/lib/eina \ -I$(top_srcdir)/src/lib/eo \ -I$(top_srcdir)/src/lib/evas \ -I$(top_srcdir)/src/lib/evas/include \ -I$(top_srcdir)/src/lib/evas/cserve2 \ @EFL_CFLAGS@ \ @EVAS_CFLAGS@ modules_evas_engines_buffer_module_la_LIBADD = lib/evas/libevas.la @EFL_LIBS@ modules_evas_engines_buffer_module_la_LDFLAGS = -no-undefined -module -avoid-version modules_evas_engines_buffer_module_la_LIBTOOLFLAGS = --tag=disable-static I have looked at the code closely, but i can't see my error Does someone know what the problem is ? forget it, i've found out what the problem is : MODULE_ARCH was empty because of a missing AC_SUBST regards Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
another solution is to just kill the stupid .la file. There is
absolutely NO reason to add to the linker static libraries that are
ONLY used in my Evil library and that are not used elsewhere.
I think that it is the best solution
thank you
Vincent Torri
On Sat, Jul 21, 2012 at 10:34 AM, Peter Rosin p...@lysator.liu.se wrote:
On 2012-07-20 17:49, Vincent Torri wrote:
hey
I'm using mingw-w64 gcc (4.8.0 experimental)
I have to link a library (named Evil) against libuuid.a. That is, in
Makefile.am :
libevil_la_LIBADD = -luuid etc..
I have the warning that I pasted in the topic:
** Warning: linker path does not have real file for library -luuid.
etc...
and no DLL is produced. I have worked around that by adding before LT_INIT :
lt_cv_deplibs_check_method='pass_all'
and I have now the DLL. I thought that it would have been sufficient.
It's not. Because of the .la files (dependency_libs fieldcontains
-luuid) , each time I link against Evil, -luuid is passed and I have
the warning above, and no DLL is produced. Even worse, some binaries
can not be compiled at all.
So I would like to know how I can forbid libtool to pass -luuid each
time I link against Evil.
I ended up with the following in a separate file to work around this
craziness. I'd also like a cleaner way to use libuuid.a/libdxguid.a
from a DLL...
Cheers,
Peter
/* libtool fails to link a dll against libdxguid.a which
* is what we really want to do here. When libtool can do
* that, kill this file and add -ldxguid to the link
* command line.
* IMHO, this is a horrid workaround. But it works, and we
* get a dll instead of a static lib.
*/
typedef struct _IID
{
unsigned long x;
unsigned short s1;
unsigned short s2;
unsigned char c[8];
} IID;
typedef IID GUID;
typedef IID CLSID;
const CLSID CLSID_DirectInput =
{0x25E609E0,0xB259,0x11CF,{0xBF,0xC7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID IID_IDirectInput2A =
{0x5944e662,0xaa8a,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const IID IID_IDirectInputDevice2A =
{0x5944e682,0xc92e,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Key =
{0x55728220,0xd33c,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_XAxis =
{0xa36d02e0,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_YAxis =
{0xa36d02e1,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_ZAxis =
{0xa36d02e2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RxAxis =
{0xa36d02f4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RyAxis =
{0xa36d02f5,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_RzAxis =
{0xa36d02e3,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_Slider =
{0xa36d02e4,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_POV =
{0xa36d02f2,0xc9f3,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysKeyboard =
{0x6f1d2b61,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
const GUID GUID_SysMouse=
{0x6f1d2b60,0xd5a0,0x11cf,{0xbf,0xc7,0x44,0x45,0x53,0x54,0x00,0x00}};
___
https://lists.gnu.org/mailman/listinfo/libtool
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin p...@lysator.liu.se wrote: On 2012-07-21 13:16, Vincent Torri wrote: another solution is to just kill the stupid .la file. There is I don't think the .la file is stupid as it lists other important dependencies. so what ? There is a HUGE problem, here. Currently, if a lib uses symbols in libuuid, it just can't be used to create progs/shared lib because the .la file lists it while it should (must) not. Static libs must not appear in the dependency_libs field. absolutely NO reason to add to the linker static libraries that are ONLY used in my Evil library and that are not used elsewhere. I think that it is the best solution That disables (easy) static linking. I, as a library author, do not like to make that policy decision for the application author. on Windows DLL are good. I already pass --disable-static to all my Windows builds. Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.
hey I'm using mingw-w64 gcc (4.8.0 experimental) I have to link a library (named Evil) against libuuid.a. That is, in Makefile.am : libevil_la_LIBADD = -luuid etc.. I have the warning that I pasted in the topic: ** Warning: linker path does not have real file for library -luuid. etc... and no DLL is produced. I have worked around that by adding before LT_INIT : lt_cv_deplibs_check_method='pass_all' and I have now the DLL. I thought that it would have been sufficient. It's not. Because of the .la files (dependency_libs fieldcontains -luuid) , each time I link against Evil, -luuid is passed and I have the warning above, and no DLL is produced. Even worse, some binaries can not be compiled at all. So I would like to know how I can forbid libtool to pass -luuid each time I link against Evil. thank you Vincent Torri ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: The case of libkmod's .so versioning attempts, and induced collisions
On Tue, Feb 7, 2012 at 3:03 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Tue, 7 Feb 2012, Jan Engelhardt wrote: Much to my disappointment, I found that the newly-released libkmod v5 has made the following non-trivial change to its source tree, the latter of which I want to bring to attention: [stuff removed] (The numbers are directly fed into libtool's -version-info argument.) As you can see, the CURRENT number was decreased, which, according to common libtool sense, is not something that one should normally do. Why do I care? Well, I happen to be active in toying with system tools (especially the ones I have to use sooner or later), as well as distro packaging, with a preference to get things right. Unfortunately, I was unable to convince the kmod people of this fact. Kay Sievers and Lucas De Marchi's argumentation is that (a) kmod is linux-only and (b) there has 'never been a libkmod.so.2' before, or even something about (c) not caring about GNU/the mess that libtool is. Hopefully your intention is only to illustrate what projects should not do and not to submit a patch. This libkmod project seems to be less than two months old and perhaps the developers still have a bit to learn about library versioning. While libtool does compute the name to apply to the library (using ELF rules), build-time (ld) and run-time (ld.so) linking is done via standard system tools and so they determine how the naming gets used. ELF is where the rules come from, not libtool. Libtool tries to make it easy to follow the ELF rules while working as best as possible with other schemes. I'm a bit surprised of that modification, as I know the guys behind libkmod, and they are good programmers. I'll try to discuss with them about that regards Vincent ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On Sat, 19 Mar 2011, LRN wrote: On 19.03.2011 0:17, Vincent Torri wrote: On Sat, 19 Mar 2011, LRN wrote: On 18.03.2011 23:51, Vincent Torri wrote: On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. It's not my library. I'm compiling mpc-0.8.2 ok. Anyway you have to pass -Wl,-no-undefined. It's an option for the linker [1], not for gcc [2] Vincent Torri [1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld [2] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options I *know* that it's a linker option. And i know that i have to pass it with -Wl because of that. What i do not know is how to make libtool see it when it is passed like that. Finally got it to work with `make libmpc_la_LDFLAGS=-version-info 2:0:0 -no-undefined', because mpc does not use AM_LDFLAGS in the link command that i'm wondering if you ever read my first answer... Vincent is used to build libmpc (mpc devs are probably the ones to blame, but right now i just want to make it work). Although i've found no way to pass such an option with spaces to `make' from a variable expansion (i.e. `make $opts'), so i've had to hard-code it into make invocation instead. I expect to find a lot of libtool-using projects that will require such hacks or workarounds, because `unrecognized option '-no-undefined'' is very common. ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On Sat, 19 Mar 2011, LRN wrote: On 18.03.2011 23:51, Vincent Torri wrote: On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. It's not my library. I'm compiling mpc-0.8.2 ok. Anyway you have to pass -Wl,-no-undefined. It's an option for the linker [1], not for gcc [2] Vincent Torri [1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld [2] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] w32 and Libtool.
On Wed, 13 Oct 2010, Peter Rosin wrote:
Hi!
I have been tinkering with a text describing the hoops to jump when
prepping a library for Windows. At some point it should be texified and
added to the manual, but I'm not the best candidate for that job so this
is plain ASCII for now.
Can you spot any errors?
not an error, but a remark. See at the bottom
(I have not actually tested the code samples. Yet)
Cheers,
Peter
Windows DLLs.
-
This topic describes a couple of ways to portably create Windows Dynamic
Link Libraries (DLLs). Libtool knows how to create DLLs using GNU tools
and using Microsoft tools.
A typical library has a hidden implementation with an interface
described in a header file. On just about every system, the interface
could be something like this:
Example foo.h:
#ifndef FOO_H
#define FOO_H
int one (void);
int two (void);
extern int three;
#endif /* FOO_H */
And the implementation could be something like this:
Example foo.c:
#include foo.h
int one (void)
{
return 1;
}
int two (void)
{
return 2;
}
int three = 3;
When using contemporary GNU tools to create the Windows DLL, the above
code will work there too, thanks to its auto-import/auto-export
features. But that is not the case when using older GNU tools or perhaps
more interesting when using proprietary tools. In those cases the code
will need additional decorations on the interface symbols with
__declspec(dllimport) and __declspec(dllexport) depending on if the
library is built or if it's consumed and how it's built and consumed.
Concentrating on how Libtool is using Microsoft tools, Libtool will dig
through the object files making up the library looking for non-static
symbols to automatically export. I.e., Libtool with Microsoft tools is
trying to mimic the auto-export feature of the contemporary GNU tools.
It should be noted that the GNU auto-export feature in turned off when
an explicit __declspec(dllexport) is seen. The GNU tools is doing this
to not make more symbols visible for projects that have already taken
the trouble to decorate all symbols. There is no similar way to limit
which symbols are visible in the code when Libtool is using Microsoft
tools. In order to limit symbol visibility in that case you need to use
one of the -export-symbols or -export-symbols-regex options.
No matching help with auto-import is provided by Libtool for neither
proprietary tools nor older GNU tools, so symbols *must* be decorated in
order to import them from a DLL for everything but contemporary GNU
tools on Windows.
When the objects that form the library are built, there are generally
two copies built for each object. One copy is used when linking the DLL
and one copy is used for the static library. On Windows systems, the
copy used when creating the DLL is compiled with the flag -DDLL_EXPORT.
It is common practice to also add a flag that is only present when the
library is built, but that will not be present when it is consumed, such
as -DBUILDING_LIBFOO. These defines are then used to discriminate how
the interface symbols should be decorated.
However, the matching double compile is not performed when consuming
libraries. It is therefore not possible to reliably distinguish if the
consumer is importing from a DLL or if it is going to use a static
library. With contemporary GNU tools, auto-import saves the day. With
Microsoft tools you typically get away with always compiling the code as
if it is going to be linked with a DLL. There are cases when this does
not work, such as when only variables and no functions are imported from
the library. There is also a price connected to this liberal use of
imports in that an extra indirection is introduced when you are
consuming the static version of the library. That extra indirection is
always present when the DLL is consumed, but it is not needed when
consuming the static library.
For older GNU tools and other proprietary tools there is no generic way
to make it possible to consume either of the DLL or the static library
without user intervention, the tools needs to be told what is intended.
Or, to be exact, the author are not aware of any generic way. One
assumption that has been used is that if a DLL is being built
(DLL_EXPORT is defined) then that DLL is going to consume any dependent
libraries as DLLs. If that assumption is made everywhere, it is possible
to select how an end user application is consuming libraries by adding a
single flag -DDLL_EXPORT when a DLL build is required. This is of course
an all or nothing deal, either everything as DLLs or everything as
static libraries.
To sum up the above, the header file of the foo library needs to be
changed into something like this:
Modified foo.h:
#ifndef FOO_H
#define FOO_H
#if (defined _WIN32 || defined _WIN32_WCE) !defined __GNUC__
_WIN32 is defined also On Windows CE if __GNUC__ is not defined (i.e.
microsoft tools are used in the Windows CE case). So it can be simplified.
Vincent Torri
Re: problem with mingw-w64 and libraries like libole32.a
Hey Any news about the problem ? so, i have provided the libtool debug output [1] and provided the informations that Charles Wilson asked me to give [2]. Any idea of the problem ? I have just found that if I add to LDFLAGS -L$HOME/local/opt/mingw64/x86_64-w64-mingw32/lib (that is the path where libole32.a is located), there is no problem. That path is in the pathsprinted with x86_64-w64-mingw32-gcc -print-search-dirs so it seems it's a libtool problem. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: w32 pending?
Hey,
Now that libtool is released, i reply the questions below
This is the Warning: linker path does not have real file for library
-lole32. problem, right?
libole32.a and friends are all part of the Win32 API, and are installed
by a proper mingw64 native non-multilib toolchain in ${prefix}/lib IIRC
-- and that dir is included in the compiler/linker's search path
automatically.
What would really help is if you could look at your (failing) libtool
script, and see what 'sys_lib_search_path_spec' is set to
# Compile-time system search path for libraries.
sys_lib_search_path_spec=/home/torri/local/opt/mingw64/lib/gcc
/home/torri/local/opt/mingw64/x86_64-w64-mingw32/lib64
-- AND (a)
where libole32.a actually lives in your setup,
/home/torri/local/opt/mingw64/x86_64-w64-mingw32/lib/libole32.a
plus (b) what 'gcc
-print-search-dirs' reports (where, 'gcc' is the actual compiler,
whatever it is called, that you are using).
install: /home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/
programs:
=/home/torri/local/opt/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../libexec/gcc/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/bin/
libraries:
=/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../lib/gcc/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.2/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/../lib64/:/buildslaves/mingw-w64/linux-x86-x86_64/build/build/root/mingw/lib/x86_64-w64-mingw32/4.5.2/:/buildslaves/mingw-w64/linux-x86-x86_64/build/build/root/mingw/lib/../lib64/:/home/torri/local/opt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.2/../../../../x86_64-w64-mingw32/lib/:/buildslaves/mingw-w64/linux-x86-x86_64/build/build/root/mingw/lib/
(*) I assume you're using a native non-multilib toolchain (you didn't
specify).
It's native (I use the linux version of the mingw-w64 toolchain). But I
don't know what multilib means :-)
thank you
Vincent Torri
Re: [PATCH] tests: import variables for MSVC.
On Fri, 24 Sep 2010, Peter Rosin wrote: Hi! I don't know how to set up the defines so that EXTERN becomes 1. extern when you use a static library 2. extern when you build a static library 3. extern declspec(dllimport) when you use a shared library 4. extern declspec(dllexport) when you build a shared library I could fix 2 and 4, but separating 1 and 3 is not possible. Since extern declspec(dllimport) works everywhere with MSVC I'm taking the easy option with this patch. Or should I add -DBUILDING_FOO to Makefile.am and variations of the below to the code? #ifdef _MSC_VER # ifdef BUILDING_FOO # ifdef DLL_EXPORT # define EXTERN extern declspec(dllexport) # endif # else # define EXTERN extern declspec(dllimport) # endif #endif #ifndef EXTERN # define EXTERN extern #endif here is what I use: http://trac.enlightenment.org/e/browser/trunk/PROTO/evil/src/lib/Evil.h#L7 It's what you do, with just an additional else in DLL_EXPORT case, without your #ifndef. works fine with gcc (mingw, mingw-w64, mingw32ce) and vc++ hth Vincent Torri
Re: w32 pending?
On Thu, 16 Sep 2010, Ralf Wildenhues wrote: Hello Chuck and Peter, do I see it right that there are no pending w32 patches for before the next Libtool release any more (after the one I just acked)? there is a mingw-w64 issue i have mentioned 2 times, with a debug log of libtool. Vincent Torri
Re: w32 pending?
On Thu, 16 Sep 2010, Ralf Wildenhues wrote: Hello Vincent, * Vincent Torri wrote on Thu, Sep 16, 2010 at 09:52:39PM CEST: On Thu, 16 Sep 2010, Ralf Wildenhues wrote: do I see it right that there are no pending w32 patches for before the next Libtool release any more (after the one I just acked)? there is a mingw-w64 issue i have mentioned 2 times, with a debug log of libtool. Yes, probably libole32 and some other libs need to be special-cased, or our acceptance of linking dlls against static libraries reconsidered. Or, this is yet another buglet in win32_libid or related functionality. But we don't have a patch for this; see above, we don't even have the issue analyzed sufficiently to know what the underlying bug is. Until that is done by somebody, we cannot address it. And who can do it ? Wasn't the log i attached in a previous mail helpful enough ? Vincent
Re: problem with mingw-w64 and libraries like libole32.a
Hey Any news about the problem ? Vincent Torri On Wed, 25 Aug 2010, Vincent Torri wrote: On Wed, 25 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST: I checked out libtool git 2 days ago and try to compile a library that uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I get the usual message: *** Warning: linker path does not have real file for library -lole32. etc... No problem with mingw. A guy from mingw-w64 told me that it worked before. Could this be a regression ? Please rerun the 'libtool --mode=link' command with --debug added as first argument after libtool, and post both the complete command as well as all output. Thanks. Command: /bin/bash ../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -Wall -Wextra -Wshadow -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/mingw64/lib -o libdl.la -rpath /home/torri/local/mingw/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la output: in the attached file. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] [cygwin] Minor sysroot fixups.
On Sat, 28 Aug 2010, Charles Wilson wrote:
libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
---
Somehow this patch got dropped when the sysroot branch
was merged. Rebased against master...
OK to push?
--
Chuck
libltdl/m4/libtool.m4 |2 +-
tests/sysroot.at |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a7141c5..e03543b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1183,7 +1183,7 @@ lt_sysroot=
case ${with_sysroot} in #(
yes)
if test $GCC = yes; then
- lt_sysroot=`$GCC --print-sysroot 2/dev/null`
+ lt_sysroot=`$CC --print-sysroot 2/dev/null`
what is the interest of testing $GCC if you use $CC ?
Vincent Torri
fi
;; #(
/*)
diff --git a/tests/sysroot.at b/tests/sysroot.at
index c0ac6d1..2a27134 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -34,7 +34,7 @@ AT_CHECK([test -n $gcc_sysroot || exit 77])
# Detect installation prefix for the compiler
prefix=
-for i in crt1.o crt2.o crti.o; do
+for i in crt0.o crt1.o crt2.o crti.o; do
j=`$CC --print-file-name $i 2 /dev/null`
test $? = 0 || continue
case $j in
--
1.7.1
Re: Link Time Optimization
On Wed, 25 Aug 2010, Werner Koch wrote: On Tue, 24 Aug 2010 21:32, ralf.wildenh...@gmx.de said: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this I assume that this only for cegcc and not for msvc, right? Given that we ported GnuPG to WinCE and that we need to maintain it for some time we should be able to test the stuff. We have build service running [1]. As of now we use a patched libtool version due to a tight development plan. For better maintenance we need to switch to regular libtool anyway and that most likely means the latest snapshots. The drawback is that we don't use all libtool features. Our group has gained quite some experience with CE and we developed a few tools (e.g. a himem loader [2]). We have not yets convinced cegcc to create thumb code; we might look into this in the next weeks. Our libs will be dayly built with some kind of buildbot. mingw, mingw-w64 and cegcc will be included. So it will also be a good test. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
Hey On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * David wrote on Tue, Aug 24, 2010 at 06:32:22PM CEST: I've been searching mailing list for supporting -flto in libtool, and seen several (commited?) patches. not yet committed, unfortunately; I had hoped for feedback from a person knowledgeable with WinCE, but that didn't happen. Oh well. sorry, i didn't follow the thread. What is the problem with WinCE ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
That's unfortunate, because it cost us a couple of months now. :-/ I Cc:ed you on the thread, was that wrong? How can we reach you? What is the problem with WinCE ? See here: http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9990 http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9769 To repeat the question: can I assume that the preprocessor symbol _WIN32_WCE is defined for wince code, and usually not defined for non-wince code? Yes. _WIN32_WCE is defined only on Windows CE platform. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Tue, 24 Aug 2010, Ralf Wildenhues wrote: Vincent, what about the other question I asked: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? English: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this for us ? Yes, I can. More precisely, i can test with cegcc. Just tell me when and what I have to do. As I have subscribed to a lot of mailing list, i have sometimes too many mails and I don't read all of them. What would be nice about the autotools ML is having, in the subject, the name of the project in bracket: Subject: [libtool] That can be done automatically (a configuration option in mailman, I guess). That would make me more aware of something important to read. regards Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
problem with mingw-w64 and libraries like libole32.a
Hey, I checked out libtool git 2 days ago and try to compile a library that uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I get the usual message: *** Warning: linker path does not have real file for library -lole32. etc... No problem with mingw. A guy from mingw-w64 told me that it worked before. Could this be a regression ? thank you Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Wed, 25 Aug 2010, David wrote: On Martes 24 Agosto 2010 21:32:13 Ralf Wildenhues escribió: * Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST: On Tue, 24 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST: I Cc:ed you on the thread, was that wrong? How can we reach you? Please answer this. Without somebody to ask about WinCE we *can* *not* support it. sorry, i don't really understand (my english is so ugly...). What do oyu want, exactly ? a mail ? English: In order to be able to support Libtool on WinCE, we need somebody to be able to test it regularly, for example before releases; also, we need to be able to ask questions about it now and then. Are you able to do this for us? I can try to ask questions in French, but it's not practical to wait months for answers. Thank you. French: Pour être en mesure de soutenir Libtool sur WinCE, nous avons besoin de quelqu'un pour être de pouvoir le tester régulièrement, par exemple, avant de presse; aussi, nous devons être en mesure de poser des questions à ce sujet ici et là. Êtes-vous capable de le faire pour nous? Je peux essayer de poser des questions en français, mais ce n'est pas pratique pour attendre des mois pour obtenir des réponses. Merci. (Cela a été traduit translate.google.com) Cheers, Ralf Instead of relying in only one person and possibly waiting for his response, how about to start supporting it in all other arches and disabling it on untested arches like WinCE? For example in compile time, or so on. That's just an idea, but I feel like lto is something that is sufficient important to be tested as soon as possible, and, imho, gives as a new interesting level of optimization. Things can also be automated a bit. Cross compilation can be done with buildbot on a server, for example. That can speed up things. Vincent Torri___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with mingw-w64 and libraries like libole32.a
On Wed, 25 Aug 2010, Ralf Wildenhues wrote: * Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST: I checked out libtool git 2 days ago and try to compile a library that uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I get the usual message: *** Warning: linker path does not have real file for library -lole32. etc... No problem with mingw. A guy from mingw-w64 told me that it worked before. Could this be a regression ? Please rerun the 'libtool --mode=link' command with --debug added as first argument after libtool, and post both the complete command as well as all output. Thanks. Command: /bin/bash ../../../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -Wall -Wextra -Wshadow -Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/mingw64/lib -o libdl.la -rpath /home/torri/local/mingw/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la output: in the attached file. Vincent Torri libtool_mingw64_output.txt.bz2 Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On Tue, 8 Jun 2010, Gary V. Vaughan wrote: [[Adding Libtool List]] On 8 Jun 2010, at 08:42, Charles Wilson wrote: Which is why I don't think even the Peter's long-ready MSVC patches, nor my pile of pending patches, are candidates for this extremely shortened release cycle. Regarding these patches, I honestly have paid very little attention to Windows fixes for libtool because I can't test them, even if you install mingw cross toolchain on linux ? You can even test Windows CE with cegcc on linux Vincent Torri and don't use them: So I figured someone else was taking care of it. Since that obviously isn't the case, and because I'd hate to see them bitrotting indefinitely in the list archives, we can either commit them on the trunk after 2.2.10, or else create a topic branch in git to collect them together for testing and merging back at an appropriate point. Chuck, Peter, you both have commit rights, correct? Would you be willing to round up those pending patches and shepherd them into the tree? I'm planning to put out a new libtool point release every few months from now on, as long as something worthwhile has been added to the code since the previous release. Note, btw, that the only reason we haven't been deluged with complaints about that latter, is that cygwin and MinGW both distribute a forked libtool package that has been patched to deal with these issues. It is *routine* on cygwin to ALWAYS reautoconf EVERY package you try to build, mostly to pull in the working libtool instead of the official libtool the package shipped with. Yikes. Well, I'd like to fix that too. If the fork is well tested already (as seems to be the case), and we can verify that merging it back into git won't cause regressions on other platforms, I'd very much like to fold all of that back into 2.2.12 for sometime in early August. If one of you would create a topic branch for unmerged Windows patches and commit the things that belong in upstream, I'll test them on the platforms I have access to, and merge them back into master if there are no issues. Or, if it turns out that they are big and destabilizing, then I'll make a 2.2.x release branch for 2.2.12, and we can start thinking about a Windows friendly 2.4.0 towards the end of the year. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Hey, On Fri, 21 May 2010, Gary V. Vaughan wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. The Libtool Team is pleased to announce release candidate 2.2.7b of GNU Libtool. If there are no serious deficiencies reported in this release, it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix any problems and put out 2.2.7d first). Just a note: i tried to compile a program for Windows CE (using cegcc) and it works, now (well, it worked with the git version, so...) thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool release status
Hey, almost everything is in the subject. 2 weeks ago, there was a thread about the release. So what is the status ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: use of shrext_cmds on mac os x (fwd)
-- Forwarded message -- Date: Fri, 23 Apr 2010 12:27:27 -0600 From: Eric Blake ebl...@redhat.com To: Vincent Torri vto...@univ-evry.fr Cc: autoc...@gnu.org Subject: Re: use of shrext_cmds on mac os x On 04/23/2010 12:09 PM, Vincent Torri wrote: Hey, on mac os x, shrext_cmds is defined like that: shrext_cmds='`test .$module = .yes echo .so || echo .dylib`' Wrong list. shrext_cmds is defined by libtool, so you may have better luck asking your question there. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org ___ http://lists.gnu.org/mailman/listinfo/libtool
module name on mac os x
Hey, A guy mentioned that problem: on mac os x, a standard shared lib has suffix name .dylib: lib_LTLIBRARIES = libfoo.la -- libfoo.dylib but with a module: pkg_LTLIBRARIES = bar.la bar_la_LDFLAGS = -module -avoid-version then the name is bar.so and not bar.dylib Is it a known behavior ? If so, is it a bug ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: module name on mac os x
On Wed, 21 Apr 2010, Peter O'Gorman wrote: On 04/21/2010 04:00 PM, Vincent Torri wrote: Hey, A guy mentioned that problem: on mac os x, a standard shared lib has suffix name .dylib: lib_LTLIBRARIES = libfoo.la -- libfoo.dylib but with a module: pkg_LTLIBRARIES = bar.la bar_la_LDFLAGS = -module -avoid-version then the name is bar.so and not bar.dylib Is it a known behavior ? If so, is it a bug ? Yes, it is known, no, it is not a bug. linux windows mac libsodll dylib module sodll so mac is the only system where the module has a different name than a lib. Why ? That complicates things for nothing (we use shrext_cmds variable in autoconf as suffix of files that are dlopened). Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.26: OpenBSD and -pthread
On Tue, 29 Dec 2009, Bob Friesenhahn wrote: tig$ eet eet:/usr/local/lib/eina/mp/eina_chained_mempool.so: undefined symbol 'pthread_mutex_unlock' Is -pthread also applied when the binary is built, or has it been lost? -pthread should also be passed to any binary that uses a lib using pthread, even if the binary itself does not use pthread directly ? If you compile a trivial hello-world type program with '-v -pthread', does the output show that an alternate libc or a threads library is being used? I'll ask the guy who reported the problem Thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 1.5.26: OpenBSD and -pthread
Hey, When passing -pthread to my_lib_LDFLAGS and my_lib_CFLAGS in Makefile.am, on OpenBSD (libtool 1.5.26), the linker does not have -lpthread, but just -pthread : gcc -shared -fPIC -DPIC -o .libs/libeina-ver-pre-svn-05.so.9.9 .libs/libeina_la-eina_error.o .libs/libeina_la-eina_log.o .libs/libeina_la-eina_hash.o .libs/libeina_la-eina_lalloc.o .libs/libeina_la-eina_inlist.o .libs/libeina_la-eina_file.o .libs/libeina_la-eina_mempool.o .libs/libeina_la-eina_list.o .libs/libeina_la-eina_matrixsparse.o .libs/libeina_la-eina_module.o .libs/libeina_la-eina_value.o .libs/libeina_la-eina_array.o .libs/libeina_la-eina_magic.o .libs/libeina_la-eina_main.o .libs/libeina_la-eina_counter.o .libs/libeina_la-eina_iterator.o .libs/libeina_la-eina_accessor.o .libs/libeina_la-eina_convert.o .libs/libeina_la-eina_fp.o .libs/libeina_la-eina_rbtree.o .libs/libeina_la-eina_benchmark.o .libs/libeina_la-eina_rectangle.o .libs/libeina_la-eina_stringshare.o .libs/libeina_la-eina_cpu.o .libs/libeina_la-eina_tiler.o .libs/libeina_la-eina_hamster.o .libs/libeina_la-eina_safety_checks.o -L/usr/local/lib -lintl -liconv -L/usr/X11R6/lib -L/lib -lm -march=prescott -msse -msse2 -msse3 -pthread -pthread Is there a known problem with OpenBSD and -pthread, using libtool 1.5.26 ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.26: OpenBSD and -pthread
On Mon, 28 Dec 2009, Bob Friesenhahn wrote: On Mon, 28 Dec 2009, Vincent Torri wrote: When passing -pthread to my_lib_LDFLAGS and my_lib_CFLAGS in Makefile.am, on OpenBSD (libtool 1.5.26), the linker does not have -lpthread, but just -pthread : Is -pthread not sufficient to do everything needed? Notice that this is GCC and not just the linker. GCC is expected to respond to -pthread. if we just pass -pthread, then a binary using the library gives, for example, the error: tig$ eet eet:/usr/local/lib/eina/mp/eina_chained_mempool.so: undefined symbol 'pthread_mutex_unlock' Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with rpath on OpenBSD
On Sun, 8 Nov 2009, Bob Friesenhahn wrote: On Sat, 7 Nov 2009, Vincent Torri wrote: The link command is: /bin/sh ../../../libtool --tag=CC --mode=link gcc -o emotion.la -rpath -module -avoid-version emotion.lo ../../../src/lib/libethumb.la -L/usr/local/lib -L/usr/X11R6/lib -levas -leet -lgnutls -lfribidi -lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -leina -L/usr/local/lib -L/usr/X11R6/lib -lemotion -levas -leet -lgnutls -lfribidi -lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -lecore -lglib-2.0 -lintl -liconv -leina -L/usr/local/lib -L/usr/local//lib -L/usr/X11R6/lib -ledje -lecore_imf_evas -lecore_imf -llua -lm -lembryo -lecore_job -lecore -lglib-2.0 -lintl -liconv -levas -lfribidi -lfontconfig -lexpat -lfreetype -lz -leet -lgnutls -leina The error is libtool: link: only absolute run-paths are allowed it seems that no value is passed to rpath (what is after it is -module) Ok, I slept last night and am looking at this again. It seems pretty clear that since no argument was supplied to -rpath that the bug is related to whatever is invoking libtool (probably a Makefile) rather than libtool itself. I also think that it is a problem with a Makefile. I'll investigate more. thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
problem with rpath on OpenBSD
Hey, a guy is trying to compile one of our libraries on OpenBSD 4.6. He is using libtool 1.5.26 The link command is: /bin/sh ../../../libtool --tag=CC --mode=link gcc -o emotion.la -rpath -module -avoid-version emotion.lo ../../../src/lib/libethumb.la -L/usr/local/lib -L/usr/X11R6/lib -levas -leet -lgnutls -lfribidi -lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -leina -L/usr/local/lib -L/usr/X11R6/lib -lemotion -levas -leet -lgnutls -lfribidi -lfontconfig -lexpat -lfreetype -lz -leina -L/usr/local/lib -lecore -lglib-2.0 -lintl -liconv -leina -L/usr/local/lib -L/usr/local//lib -L/usr/X11R6/lib -ledje -lecore_imf_evas -lecore_imf -llua -lm -lembryo -lecore_job -lecore -lglib-2.0 -lintl -liconv -levas -lfribidi -lfontconfig -lexpat -lfreetype -lz -leet -lgnutls -leina The error is libtool: link: only absolute run-paths are allowed it seems that no value is passed to rpath (what is after it is -module) I don't know which information or file i should provide to give more hints about the problem. does someone have an idea ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning and ABI
On Wed, 12 Aug 2009, Michel Briand wrote: I've looked into many OSS and found in Makefile.am only 2 cases : - version-info 1:0:0 (the guys there didn't want to bother with libtool versioning apparently... ;)) - version-info with the X.Y.Z version back crafted to make the soname version read the same as X.Y.Z if i'm not mistaken, you can compute le libtool versioning from the version of the software. If the version of the software is X.Y.Z, the libtool version can be computed with : (X+Y).Z.Y Of course the version of the software must be correctly updated. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning and ABI
On Wed, 12 Aug 2009, Ralf Wildenhues wrote: * Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST: if i'm not mistaken, you can compute le libtool versioning from the version of the software. If the version of the software is X.Y.Z, the libtool version can be computed with : (X+Y).Z.Y No, it can not, for two reasons: 1) the version of the software and the shared library version are completely unrelated; 2) you are thinking in terms of GNU/Linux shared library versioning only, not seeing that there are other systems. This thread is all about why your statement is wrong. Please read it. i've read it. But the way we change X, Y and Z follows exactly the libtool versioning (http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info) with the formula above. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning and ABI
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 07:15:16AM CEST:
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version of the software. If the version of the software is X.Y.Z,
the libtool version can be computed with : (X+Y).Z.Y
No, it can not, for two reasons: 1) the version of the software and the
shared library version are completely unrelated; 2) you are thinking in
terms of GNU/Linux shared library versioning only, not seeing that there
are other systems.
This thread is all about why your statement is wrong. Please read it.
i've read it. But the way we change X, Y and Z follows exactly the
libtool versioning
(http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info)
with the formula above.
What does that have to do with it? That statement is completely
unrelated to what you said before.
Example showing why your first statement above is wrong:
I have a package called foo, at version 2.13.
we use a micro version number, not only a major and minor version
numbers; so all you say below is unrelated to what i described above:
AC_INIT([eet], [1.2.2], [enlightenment-de...@lists.sourceforge.net])
AC_PROG_LIBTOOL
VMAJ=`echo $PACKAGE_VERSION | awk -F. '{printf(%s, $1);}'`
VMIN=`echo $PACKAGE_VERSION | awk -F. '{printf(%s, $2);}'`
VMIC=`echo $PACKAGE_VERSION | awk -F. '{printf(%s, $3);}'`
SNAP=`echo $PACKAGE_VERSION | awk -F. '{printf(%s, $4);}'`
version_info=`expr $VMAJ + $VMIN`:$VMIC:$VMIN
Vincent Torri
It consists of a lot of
junk, plus two shared libraries created with libtool, libfoo and
libbar. libfoo is currently at the Libtool version triple 3:27:0,
libbar is currently at the Libtool version triple 17:105:1.
With our foo next release, 2.14, libfoo will probably have 3:28:0,
libbar will probably have 18:3:2.
All of this is very much conforming to the link you posted. But it has
*nothing* to do with the version of the package (2.13 resp 2.14 here).
And I have not said a word about the soname of the libraries on
GNU/Linux (which is what you are trying to get the computation from).
The fact that, on GNU/Linux, the version triple 17:105:1 might cause a
library with soname libfoo.so.16 to be created, is a detail that I don't
care about. I am aware of it, and distros might have to deal with it,
but I am just as aware that on other systems, the *same* triple might
cause a library with soname libfoo.so.17.1 to be created, or with DLL
name libfoo-16.dll or what not else.
--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
Message délivré par le serveur de messagerie de l'Université d'Evry.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Damien Lespiau » shave: making the auto tools output sane
On Tue, 9 Jun 2009, Bob Friesenhahn wrote: See http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html for the announcement. The release was hastened in order to shave some lifetime from 'shave'. Another related question: would it be possible to add a % at the beginning of each compilation command ? A bit like cmake or waf. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Damien Lespiau » shave: making the auto tools output sane
On Wed, 10 Jun 2009, Vincent Torri wrote: On Tue, 9 Jun 2009, Bob Friesenhahn wrote: See http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html for the announcement. The release was hastened in order to shave some lifetime from 'shave'. Another related question: would it be possible to add a % at the beginning of each compilation command ? A bit like cmake or waf. and also a customization of the color (different color when linking or compiling) ? :-) Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Damien Lespiau » shave: making the auto tools output sane
On Tue, 9 Jun 2009, Bob Friesenhahn wrote: See http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html for the announcement. Is it possible to add AM_SILENT_RULES only when automake version is = 1.11, that is is there a good way to retrieve the version of automake in configure.ac ? Something like: AM_INIT_AUTOMAKE(1.6 dist-bzip2) if test $AUTOMAKE_CURRENT_VERSION -ge 1.1 ; then AM_SILENT_RULES fi I think that i can get it by using sed on what is returned by 'automake -version', but i would prefer an autotools way thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
fix of the c wrapper for the cegcc hosts
Hey,
here is a patch that does not generate the c wrapper when cegcc hosts
(cegcc and mingw32ce) are used.
regards
Vincent Torridiff --git a/ChangeLog b/ChangeLog
index e278549..cb6ac68 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-06-07 Vincent Torri vtorri at univ-evry dot fr
+
+ Fix C wrapper invocation for ceGCC hosts (cegcc and mingw32ce)
+ * libltdl/config/ltmain.m4sh (func_mode_link): do not generate
+ C wrapper for cegcc and mingw32ce hosts.
+ (func_emit_cwrapperexe_src): remove useless check on __MINGW32CE__
+
2009-06-06 Richard Sandiford richa...@transitive.com
Fix GNU nm invocation for AIX.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 5609304..72660a8 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2738,9 +2738,7 @@ EOF
#include assert.h
#include string.h
#include ctype.h
-#ifndef __MINGW32CE__
-# include errno.h
-#endif
+#include errno.h
#include fcntl.h
#include sys/stat.h
@@ -2770,7 +2768,7 @@ int setenv (const char *, const char *, int);
# define _INTPTR_T_DEFINED
# define intptr_t int
# endif
-#elif defined(__MINGW32__) !defined(__MINGW32CE__)
+#elif defined(__MINGW32__)
# define setmode _setmode
# define stat_stat
# define chmod _chmod
@@ -3145,11 +3143,7 @@ EOF
if (rval == -1)
{
/* failed to start process */
-#ifndef __MINGW32CE__
LTWRAPPER_DEBUGPRINTF (((main) failed to launch target \%s\: errno = %d\n, lt_argv_zero, errno));
-#else
- LTWRAPPER_DEBUGPRINTF (((main) failed to launch target \%s\\n, lt_argv_zero));
-#endif
return 127;
}
return rval;
@@ -3378,12 +3372,8 @@ chase_symlinks (const char *pathspec)
}
else
{
-#ifndef __MINGW32CE__
char *errstr = strerror (errno);
lt_fatal (Error accessing file %s (%s), tmp_pathspec, errstr);
-#else
- lt_fatal (Error accessing file %s, tmp_pathspec);
-#endif
}
}
XFREE (tmp_pathspec);
@@ -7411,15 +7401,15 @@ EOF
wrappers_required=yes
case $host in
+ *cegcc* | *mingw32ce*)
+# Disable wrappers for cegcc and mingw32ce hosts, we are cross compiling anyway.
+wrappers_required=no
+;;
*cygwin* | *mingw* )
if test $build_libtool_libs != yes; then
wrappers_required=no
fi
;;
- *cegcc*)
-# Disable wrappers for cegcc, we are cross compiling anyway.
-wrappers_required=no
-;;
*)
if test $need_relink = no || test $build_libtool_libs != yes; then
wrappers_required=no
Re: purpose of the c wrapper
On Sun, 7 Jun 2009, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Jun 07, 2009 at 08:33:42AM CEST: 1) remove the wrapper for cegcc and mingw32ce host (see the patch i sent) 2) remove the #ifndef __MINGW32CE__ the in windows wrapper, they are useless. Thank you for explaining. I agree with your reasoning. Can you please send a patch that does the above, including a ChangeLog entry, to the libtool-patches list? I will apply it then. is there a prefered way to update ChangeLog (i usually use moap) ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Hey, * Vincent Torri wrote on Wed, Jun 03, 2009 at 09:32:50PM CEST: Does there exist a simulator for wince? Even if not now, can there exist one at some point? In that case, we should strive to not make things harder for that setup. there is a simulator for Windows CE that can be run on linux. But it is a pain to setup and to use, and i never succeeded in using it for graphic programs (which is the purpose of the libraries I'm porting). Hmm. But libtool aims to be usable not just for you. Oh well, I guess we've been there before, but no other user has shown up yet. well, the emulator is not really usable on linux, and it emulates only some versions of Windows CE, not all. The file link_output.txt is the result of the command : /bin/bash ../../libtool --tag=CC --debug --mode=link arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -L/home/torri/local/wince/lib -Wl,-s -o test_evil.exe test_evil.o ../../src/lib/libevil.la link_output.txt 21 My version of libtool : 2.2.6 Well, we've been through this before, too. You and I have put in fixes for this bit after 2.2.6 was released, the relevant one seems to be in 4e7334c7c28e51d3943339f6f3617985c03e3f79. Try current git or a nightly snapshot, it will set $wrappers_required to no, I have just tried with the latest git of libtool. And I have exactly the same problem, $wrappers_required is set to 'yes'. I think that I know why. wrappers_required is set to 'no' only if cegcc is used. I should be a bit more precise: The cegcc framework provide 2 sets of cross compilation toolchain: a) 'cegcc', which provides a POSIX emulation (a kind of cygwin for win ce) b) 'mingw32ce', which provides a native compilation toolchain in ltmain.m4sh, only cegcc is mentioned. mingw32ce should also be mentioned. Here is below a patch, which fixes the problem. Note that I have to put the test before *cygwin* | *mingw* because otherwise, mingw32ce will fall into that case (which was actually the case) Vincent Torri diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 5609304..778666b 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -7411,15 +7411,15 @@ EOF wrappers_required=yes case $host in + *cegcc* | *mingw32ce* ) +# Disable wrappers for cegcc and mingw32ce, we are cross compiling anyway. +wrappers_required=no +;; *cygwin* | *mingw* ) if test $build_libtool_libs != yes; then wrappers_required=no fi ;; - *cegcc*) -# Disable wrappers for cegcc, we are cross compiling anyway. -wrappers_required=no -;; *) if test $need_relink = no || test $build_libtool_libs != yes; then wrappers_required=no ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
On Thu, 4 Jun 2009, Roumen Petrov wrote:
Ralf Wildenhues wrote:
Hello Vincent, Bob,
[SNIP]
But anyway, I don't see how the current git code generates C wrappers
for wince.
The host is usually xxx-mingw32ce and will match patterns like {*-}*-mingw*,
i.e. it will generate wrappers as for mingw32.
i have just sent a mail with a patch for that.
But the C-wrapper-code of current (my repository close is about one month
old) libtool don't include error.h :
.
#ifndef __MINGW32CE__
# include errno.h
#endif
and if the patch os accepted, you can remove the 3 #ifndef __MINGW32CE__
that are in the wrapper for cygwin / mingw
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
On Tue, 2 Jun 2009, Bob Friesenhahn wrote: On Tue, 2 Jun 2009, Vincent Torri wrote: So, the first line is the link of my real binary (evil_suite.exe), then the compilation of the c wrapper is done and is failing. If I run make install, evil_suite.exe is not installed. This is expected behavior since the Makefile uses the wrapper binary as the target and libtool takes care of building the files in .libs as a sort of side-effect (please ignore the man behind the curtain). If you put any file at all in place of the wrapper (e.g. 'touch evil_suite.exe') then it seems likely that make install would work. I don't know enough about Windows CE to know if a wrapper executable can be made to work at all. Imho, the wrapper will never work (as i can't execute Windows CE code when i'm cross-compiling) and hence is useless for that platform. How can it be disabled when using cegcc / mingw32ce ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
purpose of the c wrapper
Hey, I am trying to port the c wrapper that is generated on MSYS/MinGW to the mingw32ce platform (for Windows CE OS). On that OS, there are some missing features that exists on other OS (no environment variable (hence no getenv / setenv / putenv), no current working directory, no spawn function, etc...). I can't port correctly it if I don't know the purpose of the C wrapper. I have asked several times that question on that list and I have never had a precise answer. So I ask again: what the precise purpose of the C wrapper ? Don't hesitate to give a long and detailed answer. thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
On Mon, 1 Jun 2009, Bob Friesenhahn wrote: The purpose is to allow unininstalled (in build tree) executables and libraries to be executed. Without this, it is difficult to debug and test the uninstalled executables. It does not sound like Windows CE offers enough functionality to make this possible. So what should be done to disable the execution of the c wrapper on that platform only ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool links with g++ even with only c file
hey i have written a library which can be compiled for windows xp or windows ce. The source files are only C files with windows ce, and there is a c++ file with windows xp. when i compile for windows ce, only gcc i used, but the link uses g++ to create the DLL. There is also no c++ flags. Is there a reason why libtool still uses g++ to create the DLL ? if you need more informations (configure.ac or Makefile.am files), tell me thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool links with g++ even with only c file
Hey, * Vincent Torri wrote on Sat, Apr 18, 2009 at 09:45:24AM CEST: i have written a library which can be compiled for windows xp or windows ce. The source files are only C files with windows ce, and there is a c++ file with windows xp. I assume that this C++ file is added with an Automake conditional. indeed when i compile for windows ce, only gcc i used, but the link uses g++ to create the DLL. There is also no c++ flags. Is there a reason why libtool still uses g++ to create the DLL ? This is an Automake question. automake doesn't take into account conditionals when deciding which linker to use (this is a bug or limitation or feature, depending on how you see it). sorry for using the wrong ML. Anyway, you can work around it by setting foo_LINK. Here's an example. ok, so it's just a matter of using the correct link options thank you Vincent Torri cat configure.ac 'END' AC_INIT(a,1) AM_INIT_AUTOMAKE(foreign) AC_PROG_CC AC_PROG_CXX AM_CONDITIONAL(COND, false) AC_CONFIG_FILES(Makefile) AC_OUTPUT END cat Makefile.am 'END' bin_PROGRAMS = foo foo_SOURCES = foo.c if COND foo_SOURCES += bar.cc foo_LINK = $(CXXLINK) else foo_LINK = $(LINK) endif END ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool links with g++ even with only c file
On Sat, 18 Apr 2009, Vincent Torri wrote: Hey, Anyway, you can work around it by setting foo_LINK. Here's an example. ok, so it's just a matter of using the correct link options another question related to that. I have that following code: libevil_la_LDFLAGS = -no-undefined -Wl,--enable-auto-import -version-info @version_info@ if EVIL_HAVE_WINCE libevil_la_LINK = $(LINK) else libevil_la_CXXFLAGS = -fno-rtti -fno-exceptions libevil_la_LINK = $(CXXLINK) endif But now, it seems that libevil_la_LDFLAGS is not taken into account anymore. What should I do ? pass its value to libevil_la_LINK ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool links with g++ even with only c file
On Sat, 18 Apr 2009, Ralf Wildenhues wrote: * Vincent Torri wrote on Sat, Apr 18, 2009 at 07:13:11PM CEST: On Sat, 18 Apr 2009, Vincent Torri wrote: Anyway, you can work around it by setting foo_LINK. ok, so it's just a matter of using the correct link options another question related to that. I have that following code: libevil_la_LDFLAGS = -no-undefined -Wl,--enable-auto-import -version-info @version_info@ if EVIL_HAVE_WINCE libevil_la_LINK = $(LINK) else libevil_la_CXXFLAGS = -fno-rtti -fno-exceptions libevil_la_LINK = $(CXXLINK) endif But now, it seems that libevil_la_LDFLAGS is not taken into account anymore. What should I do ? pass its value to libevil_la_LINK ? Ouch, I didn't think of that. Well, one thing you can do is to take out the libevil_la_LINK variables again and look at how automake sets it; use the same string to override them (it will include $(libevil_la_LDFLAGS)). Arguably, this approach kind of exploits internal Automake details. According to the value in the Makefile, this: if EVIL_HAVE_WINCE libevil_la_LINK = $(LINK) $(libevil_la_CFLAGS) $(libevil_la_LDFLAGS) else libevil_la_CXXFLAGS = -fno-rtti -fno-exceptions libevil_la_LINK = $(CXXLINK) $(libevil_la_CXXFLAGS) $(libevil_la_LDFLAGS) endif is sufficient. The *_C(XX)FLAGS can even be removed. Technically, its value should not contain linker flags. thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 1.5.2* problem
Hey, I know that libtool 1.5.2* is a very old version, not maintained anymore, but i would like to know if the problem that I have is related to that version or not. I cross compile to have a Windows dll (in case it matters) I link a lib named 'toto' against libfoo.la. In libfoo.la, in the dependency_libs variable, I have libbar.la. but the link command that creates libtoto.dll does not mention libbar.a file, nor all the dependencies that are in dependency_libs of libfoo.la Is it a known behavior with that version of libtool ? Note that there is no problem with libtool 2.2.* thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.2* problem
On Thu, 16 Apr 2009, Ralf Wildenhues wrote: Hello Vincent, * Vincent Torri wrote on Thu, Apr 16, 2009 at 01:04:00PM CEST: I know that libtool 1.5.2* is a very old version, not maintained anymore, but i would like to know if the problem that I have is related to that version or not. I cross compile to have a Windows dll (in case it matters) I link a lib named 'toto' against libfoo.la. In libfoo.la, in the dependency_libs variable, I have libbar.la. but the link command that creates libtoto.dll does not mention libbar.a file, nor all the dependencies that are in dependency_libs of libfoo.la Is it a known behavior with that version of libtool ? Note that there is no problem with libtool 2.2.* Most likely your 1.5.2* is from Debian which, on GNU/Linux, enables link_all_deplibs=no which the FSF version doesn't do. Hmm, maybe some old FSF version did, but then backed that out again, I don't remember. it's indeed a debian. You can find out with ./libtool --config | grep ^link_all_deplibs= i get: link_all_deplibs=unknown Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Wed, 21 Jan 2009, Charles Wilson wrote: Vincent Torri wrote: here is a reminding of something that i reported 2 months ago: (see http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). I recall the facts: when using the mingw32ce compiler, func_emit_cwrapperexe_src() fails, hence the installation of the binaries is not done. That function fails because several functions do not exist on that platform. They are: * getenv, putenv (no environment variable on that OS) * getcwd (no current working directory feature too) * _spawn() The simple way would be to guard them, like it was done with errno: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3 Well, not really. The whole purpose of the wrapper (executable, or shell script on unix platforms) is to *set environment variables* appropriately before invoking the actual target executable -- especially $PATH on win32 so that the target executable can find the newly-built and not-yet-installed DLLs that it needs. How wince handles that with no environment variables I have no idea. Maybe if it has no directories at all (and hence, no current working directory), then finding DLLs it not really an issue. I dunno. there are directories, BUT, and that's one of the incredible issues on that OS (there are others...): the directory is not taken into account when looking for a dll. That is, you should avoid having 2 dll with the same name. Otherwise, only one will be always used. Which one, I don't know. But that's a limitation of the OS. Incredible, isn't it ? But most of that can be worked-around using stub functions in the wrapper executable (e.g. wince_setenv() that does nothing and returns success, etc). If it's not a problem for the wrapper, it's fine to me. What can't be worked-around is: _spawn. Somehow there MUST be a way for one executable on wince to start another process. Maybe by invoking CreateProcess() directly -- whereas the normal win32 C runtime provides the _spawn functions as posix-like wrappers around the core Win32API CreateProcess(). CreateProcess can be used, I guess. I'm not a windows programmer. I just ported linux libraries to that terrible OS. I guess there are two choices: (1) do we need the wrapper (executable) to work -- that is, can you invoke the wrapper executable within the target environment (a wince emulator, perhaps?) and if so, do we need it to perform as advertised: set up the proper environment (whatever that means, if anything, given no env vars) and handover control within the simulator environment to the actual executable, in .libs/$myexe? I always do cross-compilation for that OS. I compile on linux. Then I copy the dll / binaries with a SD card. So I don't need it, I think If the answer to either question is no, then perhaps the answer is (2) just to ensure that the wrapper executable compiles without error, even if it is utterly non-functional on wince. That's a little...disturbing, but then, I'm not involved with wince. FYI: the re-organized includes and portability macros part of this patch: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89. http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg4.html was done with an eye toward making these wince workarounds a little easier. I hope. ok Oh, there also might be a third option, but I could be exposing more of my ignorance: maybe wince could just set $needs_wrapper false always, regardless of whether the build is static or dynamically linked? However, what this all boils down to, is somebody is going to have to write the patch, and test it, using mingw32ce. That's going to have to be someone actively involved in using mingw32ce and the wince OS. That ain't me. And given that your original post was 2 months ago, with little response, it looks like very few of the list denizens, other than yourself, have the expertise to directly tackle the problem. I can provide patches, but, as I already said, I'm not involved in libtool dev and I can't write patches if i'm not helped. I have not time to dig into libtool code, as i already have not a lot of time to work on my own todo list. I can compile libtool, run tests, see if my libs compiles flawlessly with libtool. So, according to what I've said, what do you think it is best for that wrapper ? Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, here is a reminding of something that i reported 2 months ago: (see http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). I recall the facts: when using the mingw32ce compiler, func_emit_cwrapperexe_src() fails, hence the installation of the binaries is not done. That function fails because several functions do not exist on that platform. They are: * getenv, putenv (no environment variable on that OS) * getcwd (no current working directory feature too) * _spawn() The simple way would be to guard them, like it was done with errno: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3 I don't know if that way would break or not that function Here is the output I have: ./.libs/lt-evil_suite.c: In function 'find_executable': ./.libs/lt-evil_suite.c:620: warning: initialization makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_opt_process_env_prepend': ./.libs/lt-evil_suite.c:880: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_opt_process_env_append': ./.libs/lt-evil_suite.c:901: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_update_exe_path': ./.libs/lt-evil_suite.c:917: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-evil_suite.c: In function 'lt_update_lib_path': ./.libs/lt-evil_suite.c:938: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast /tmp/cchXYNpc.o: In function `lt_setenv': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:790: undefined reference to `putenv' /tmp/cchXYNpc.o: In function `lt_update_lib_path': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:938: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `lt_update_exe_path': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:917: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `lt_opt_process_env_append': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:901: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `lt_opt_process_env_prepend': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:880: undefined reference to `getenv' /tmp/cchXYNpc.o: In function `find_executable': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:620: undefined reference to `getenv' /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:635: undefined reference to `getcwd' /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:660: undefined reference to `getcwd' /tmp/cchXYNpc.o: In function `main': /home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:484: undefined reference to `_spawnv' collect2: ld returned 1 exit status arm-mingw32ce-strip: './evil_suite.exe': No such file ../../libtool: line 8551: $func_ltwrapper_scriptname_result: ambiguous redirect thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 7 Dec 2008, Roumen Petrov wrote: the issue is that 'make install' installs no executables at all. Vincent, I can't reproduce with testcase from attached file lt-mingw-nowine-bootstrap.sh.gz (Note my emulator is not in /bin:/usr/bin). sorry, i was not precise enough. So: 1) with the host i586-mingw32msvc, I have the warnings and the installation succeeds 2) with the host mingw32ce, I have the warnings (and some errors I already mentioned) and the installation fails Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, On Mon, 8 Dec 2008, Ralf Wildenhues wrote: For the second case, the mingw32ce one, please show exactly the failure output; i.e., if 'make install' fails, then copy and paste all of its output. Then, in that output, find the 'libtool --mode=install' command that failed, rerun it manually (in the correct directory), with --debug added as first argument after 'libtool'. Copy and paste all of that output. Then, remove the program/library that was going to be installed, from the build directory, so 'make' rebuilds it. Find that --mode=link command, and execute it with --debug as well, and post that, too. maybe the issues i have reported in that mail: http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html should be fixed first Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sat, 6 Dec 2008, Roumen Petrov wrote: You environment lack emulator, or winepath isn't in PATH. WHY do I need an emulator ? I don't care about that. I just want my executables being installed (copied) in the prefix/bin directory I passed when I exec 'make install'. That's all. WHY does libtool does not want to do so ? Is there a way to forbid libtool executing that wrapper ? like -do-not-exec-the-stupid-wrapper Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLLs on mingw
Hey, I fixed the problem by adding an explicit -no-undefined to the libtool link command - is this considered to be the correct fix or am I missing something obvious? This is correct. If you use AM_PROG_LIBTOOL or AC_PROG_LIBTOOL in your configure.ac script, add AC_LIBTOOL_WIN32_DLL just before. This way is deprecated If you use LT_INIT, pass win32-dll to it In both case, you have to pass -no-undefined to libtool (during linking). See http://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIT regards Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: func_emit_cwrapperexe_src() errors with mingw32ce
On Fri, 28 Nov 2008, Roumen Petrov wrote: Natively, the Windows CE OS has no concept of environment variable. Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because of missing getenv() and putenv() (or setenv() also, of course). I don't know what to do here (removing or not thee calls, as I don't know why they are used. There are also 2 other functions that are missing with that compiler: * getcwd() May be a port function that return always \Temp is work around? it's possible to get the path where the current process is launched. Again, i don't know if it's simpler to remove that call or if one should provide a way to have the path where the process is launched. * _spawnv() A code based on CreateProcess ? If wince lack working emulator may libtool omit creation of wrapper ? I absolutely don't know as i don't know the purpose of that function. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, * Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST: libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. Do you still have this problem, and if yes, is there anything wrong *except* for the warnings? I have downloaded the git repo this morning and I still have these warnings. Do you have an explanation, btw ? About problems, I sent 1 mail this morning related to the compilation with mingw32ce. Do you have/does there exist a simulator for mingw32ce, i.e., can you execute WinCE binaries on your host system in the cross compile setup? I have an ipaq and I execute my progs on it. If yes, do they see Windows-style paths (C:\...), and if yes, how do they look like, or do they see unix-style paths? in the Windows CE OS, there is only one disk and one root, a bit like unix fs. It should understand \ and / as separators, but I know for sure that \ is working. so a typical absolute path is: \efl\expedite\data for example Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
error when helptoman is missing
Hey, I just want to mention that, with the newest git (taken 10 minutes ago), when compiling libtool with no help2man available, I get an error: /home/torri/tmp/gitroot/libtool/libltdl/config/missing: line 54: help2man : commande introuvable followed by a warning. Of course, after having installed help2man, there is no problem. Maybe configure should check the availability of help2man and the doc should be built accordingly. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
func_emit_cwrapperexe_src() errors with mingw32ce
Hey, Natively, the Windows CE OS has no concept of environment variable. Hence, when mingw32ce is used, func_emit_cwrapperexe_src() fails because of missing getenv() and putenv() (or setenv() also, of course). I don't know what to do here (removing or not thee calls, as I don't know why they are used. There are also 2 other functions that are missing with that compiler: * getcwd() it's possible to get the path where the current process is launched. Again, i don't know if it's simpler to remove that call or if one should provide a way to have the path where the process is launched. * _spawnv() i don't know any simple way to fake that function. Maybe one should add another test in the 'host' case for that specific compiler which wo do nothing (in that case, one can remove the #ifndef in the case the host is mingw*) Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw win64 comatibility
On Sun, 23 Nov 2008, Ralf Wildenhues wrote: * Alon Bar-Lev wrote on Thu, Nov 13, 2008 at 10:45:23AM CET: --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2156,7 +2156,7 @@ func_win32_libid () ;; *ar\ archive*) # could be an import, or static if eval $OBJDUMP -f $1 | $SED -e '10q' 2/dev/null | - $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null ; then + $EGREP 'file format pe-i386(.*architecture: i386)?|file format pe-x86-64' /dev/null ; then may I recall that I am waiting a similar patch for Windows CE ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Mon, 27 Oct 2008, Ralf Wildenhues wrote: It would help if you posted, for a library where this fails, the output of the './libtool --mode=link' line with --debug added as first argument; the command is: /bin/sh ../../../libtool --debug --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la libtool_link.txt 21 the result is in the attached file libtool_link.txt also, please post the output of ./libtool --tag=CXX --config the result is in the attached file libtool_config.txt thank you Vincent Torrilibtool: enabling shell trace mode + test 17 -gt 0 + opt=--tag=CC + shift + case $opt in + func_opt_split --tag=CC + func_opt_split_opt=--tag + func_opt_split_arg=CC + set dummy --tag CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + shift + test 18 -gt 0 + opt=--tag + shift + case $opt in + test 17 -eq 0 + preserve_args=' --debug --tag CC' + func_enable_tag CC + tagname=CC + re_begincf='^# ### BEGIN LIBTOOL TAG CONFIG: CC$' + re_endcf='^# ### END LIBTOOL TAG CONFIG: CC$' + sed_extractcf='/^# ### BEGIN LIBTOOL TAG CONFIG: CC$/,/^# ### END LIBTOOL TAG CONFIG: CC$/p' + case $tagname in + case $tagname in + shift + test 16 -gt 0 + opt=--mode=link + shift + case $opt in + func_opt_split --mode=link + func_opt_split_opt=--mode + func_opt_split_arg=link + set dummy --mode link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + shift + test 17 -gt 0 + opt=--mode + shift + case $opt in + test 16 -eq 0 + case $1 in + mode=link + shift + test 15 -gt 0 + opt=arm-mingw32ce-gcc + shift + case $opt in + nonopt=arm-mingw32ce-gcc + break + case $host in + opt_duplicate_compiler_generated_deps=: + : 1 + false + func_check_version_match + test 1.3012 '!=' 1.3012 + test yes '!=' yes + test -z link + eval 'std_shrext=.dll' ++ std_shrext=.dll + test -n '' + generic_help='Try `libtool --help'\'' for more information.' + help='Try `libtool --help --mode=link'\'' for more information.' + false + test link = compile + false + test link = execute + test link = finish + test link = install + test link = link + func_mode_link -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + set -x + case $host in + allow_undefined=yes + libtool_args=arm-mingw32ce-gcc + base_compile='arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la' + compile_command=arm-mingw32ce-gcc + finalize_command=arm-mingw32ce-gcc + compile_rpath= + finalize_rpath= + compile_shlibpath= + finalize_shlibpath= + convenience= + old_convenience= + deplibs= + old_deplibs= + compiler_flags= + linker_flags= + dllsearchpath= ++ pwd + lib_search_path=/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs + inst_prefix_dir= + new_inherited_linker_flags= + avoid_version=no + dlfiles= + dlprefiles= + dlself=no + export_dynamic=no + export_symbols= + export_symbols_regex= + generated= + libobjs= + ltlibs= + module=no + no_install=no + objs= + non_pic_objects= + precious_files_regex= + prefer_static_libs=no + preload=no + prev= + prevarg= + release= + rpath= + xrpath= + perm_rpath= + temp_rpath= + thread_safe=no + vinfo= + vinfo_number=no + weak_libs= + single_module=-Wl,-single_module + func_infer_tag arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libdl.la -rpath /home/torri/local/wince/lib libdl_la-dlfcn.lo ../../../src/lib/libevil.la + set -x + test -n 'CXX ' + test -z CC + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + for arg in '$@' + case $arg in + test -n '' + test 14 -gt 0 + arg=-g + shift + func_quote_for_eval -g + case $1 in + func_quote_for_eval_unquoted_result=-g + case $func_quote_for_eval_unquoted_result
Re: problem when cross compiling with mingw32ce
Hey, Now I have a problem with libm.a. The ptch you provided is good for all the static lib i currently used, but recently i had to use libm.a (more precisely, it's libtool which adds -lm when c++ code is used). Here are some output: * arm-mingw32ce-objdump -f ~/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a: _libm_dummy.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: HAS_RELOC, HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x * arm-mingw32ce-nm -f posix -A ~/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_abbrev N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_info N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .debug_line N /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libm.a[_libm_dummy.o]: .text t that's all. Should I provide more informations ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool wrapper: mingw32ce does not support errno
On Thu, 9 Oct 2008, Ralf Wildenhues wrote:
Hello Vincent,
* Vincent Torri wrote on Thu, Oct 09, 2008 at 07:02:56AM CEST:
here is a patch that removes compilation errors with mingw32ce because it
does not support the errno system.
Is __MINGW32CE__ even defined for that system? Because the patch just
looks like it's doing exactly the opposite of what you need (and that
means it would work for you only if __MINGW32CE__ is not defined).
arg, i didn't copy/paste from my libtool script and used #ifdef instead of
#ifndef. And yes, that macro exists when that compiler is used.
I don't know if it is the best solution, but it is working for me. So if
you have a better solution, feel free to modify that patch
You've gone this far now, how about you try to redo the patch based on
the comment above, then try to write a ChangeLog entry for it, too, and
then we look at it again? I'm sure you can do it!
done, but seriously, you can do it too...
Vincent Torridiff --git a/ChangeLog b/ChangeLog
index cabc93d..a41264f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2008-10-09 Ralf Wildenhues [EMAIL PROTECTED]
+
+ Do not use errno system in func_emit_cwrapperexe_src()
+ with the mingw32ce compiler
+ * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): Do not
+ include errno.h and remove calls related to errno when using the
+ mingw32ce compiler.
+
2008-10-05 Ralf Wildenhues [EMAIL PROTECTED]
Atomic shared library install permissions on HP-UX.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 696b6ab..a09c5be 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2780,7 +2780,9 @@ int setenv (const char *, const char *, int);
#include assert.h
#include string.h
#include ctype.h
-#include errno.h
+#ifndef __MINGW32CE__
+# include errno.h
+#endif
#include fcntl.h
#include sys/stat.h
@@ -3171,7 +3173,11 @@ EOF
if (rval == -1)
{
/* failed to start process */
+#ifndef __MINGW32CE__
LTWRAPPER_DEBUGPRINTF (((main) failed to launch target \%s\: errno =
%d\n, lt_argv_zero, errno));
+#else
+ LTWRAPPER_DEBUGPRINTF (((main) failed to launch target \%s\\n,
lt_argv_zero));
+#endif
return 127;
}
return rval;
@@ -3400,8 +3406,12 @@ chase_symlinks (const char *pathspec)
}
else
{
+#ifndef __MINGW32CE__
char *errstr = strerror (errno);
lt_fatal (Error accessing file %s (%s), tmp_pathspec, errstr);
+#else
+ lt_fatal (Error accessing file %s, tmp_pathspec);
+#endif
}
}
XFREE (tmp_pathspec);
libtool wrapper: mingw32ce does not support errno
hey,
here is a patch that removes compilation errors with mingw32ce because it
does not support the errno system.
I don't know if it is the best solution, but it is working for me. So if
you have a better solution, feel free to modify that patch
thank you
Vincent Torridiff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 696b6ab..6bf0c5b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2780,7 +2780,9 @@ int setenv (const char *, const char *, int);
#include assert.h
#include string.h
#include ctype.h
-#include errno.h
+#ifdef __MINGW32CE__
+# include errno.h
+#endif
#include fcntl.h
#include sys/stat.h
@@ -3171,7 +3173,11 @@ EOF
if (rval == -1)
{
/* failed to start process */
+#ifdef __MINGW32CE__
LTWRAPPER_DEBUGPRINTF (((main) failed to launch target \%s\: errno =
%d\n, lt_argv_zero, errno));
+#else
+ LTWRAPPER_DEBUGPRINTF (((main) failed to launch target \%s\\n,
lt_argv_zero));
+#endif
return 127;
}
return rval;
@@ -3400,8 +3406,12 @@ chase_symlinks (const char *pathspec)
}
else
{
+#ifdef __MINGW32CE__
char *errstr = strerror (errno);
lt_fatal (Error accessing file %s (%s), tmp_pathspec, errstr);
+#else
+ lt_fatal (Error accessing file %s, tmp_pathspec);
+#endif
}
}
XFREE (tmp_pathspec);
Re: problem when cross compiling with mingw32ce
On Wed, 8 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which i do
not have with other compilers):
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
[...]
I've never seen those message. Again, I would like to know what is
happening.
No idea where I should look in ltmain.sh to fix those messages ?
Please provide more information, like exactly how you invoked configure,
post the command that was used that produced the above output, and all
its output, not just the warnings.
configure call:
./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2
-Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
memcpy_glibc_arm.o ../../src/lib/libevil.la
libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o
.libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o
-L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib
../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/wince/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine host path corresponding to
libtool: link:
'/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs'
libtool: link: Continuing, but uninstalled executables may not work.
Libtool try to convert path from build system to the path from host
system.
So, where and how can I correct that in ltmain.sh
In file included from ./.libs/lt-suite.c:40:
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25:
error: no include path in which to search for errno.h
./.libs/lt-suite.c: In function 'find_executable':
./.libs/lt-suite.c:617: warning: initialization makes pointer from
integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend':
./.libs/lt-suite.c:873: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_opt_process_env_append':
./.libs/lt-suite.c:894: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_exe_path':
./.libs/lt-suite.c:910: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
./.libs/lt-suite.c: In function 'lt_update_lib_path':
./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
arm-mingw32ce-strip: './suite.exe': No such file
About the errno problem, I've sent a mail about that.
There is also a problem with Windows CE: there is no environment
variables in that OS, hence no getenv / setenv functions.
If exist emulator for this host os libtool may generate binary wrapper.
If I remember well the libtool contain cases for *mingw* (or *mingw32*)
and may be this is problem - mingw32ce isn't for this category.
maybe. I don'tt know much about how ltmain.sh works.
Nevertheless, I have a question about all that stuff:
for me, libtool is about libraries (libtool == library tool ?). Anyway, the
doc is saying that libtool is for making life easier when dealing with
libraries. So why is libtool so much involved when dealing with binaries
(it is my case here) ??
The libtool create wrapper script to allow user to run tests programs.
The wrapper script set environment so that test programs to use project
libraries , not system one. For the w32 platform since libtool version
2.{2|4}(?) the wrapper script is replaces by binary executable.
The host triplet *-*-mingw* is used in scripts to detect mingw build for
win32
Re: problem when cross compiling with mingw32ce
On Wed, 8 Oct 2008, Roumen Petrov wrote: Libtool try to convert path from build system to the path from host system. So, where and how can I correct that in ltmain.sh ? any idea ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
func_emit_cwrapperexe_src() with mingw32ce: errno does not exist
Hey, in the function func_emit_cwrapperexe_src(), errno.h is automatically included. But errno system does not exist on Windows CE and that file does not exist. can it be guarded with __MINGW32CE__ ? errno is also used with LTWRAPPER_DEBUGPRINTF and with strerror in ltmain.sh. I think that these 2 calls must be guarded and something else should be displayed when migw32ce is used. thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Hey, Even if i'm still waiting for an answer about the func_win32_libid() function, here is the 2nd problem: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. [...] I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? Please provide more information, like exactly how you invoked configure, post the command that was used that produced the above output, and all its output, not just the warnings. configure call: ./configure --host=arm-mingw32ce --prefix=/home/torri/local/wince libtool call: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o ../../src/lib/libevil.la libtool: link: arm-mingw32ce-gcc -g -O2 -Wl,--enable-auto-import -o .libs/suite.exe suite.o test_memcpy.o memcpy_glibc_arm.o -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib ../../src/lib/.libs/libevil.dll.a -lws2 -L/home/torri/local/wince/lib libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/tmp/svnroot_wince/e17/proto/evil/src/lib/.libs' libtool: link: Continuing, but uninstalled executables may not work. In file included from ./.libs/lt-suite.c:40: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/include/errno.h:12:25: error: no include path in which to search for errno.h ./.libs/lt-suite.c: In function 'find_executable': ./.libs/lt-suite.c:617: warning: initialization makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_prepend': ./.libs/lt-suite.c:873: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_opt_process_env_append': ./.libs/lt-suite.c:894: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_exe_path': ./.libs/lt-suite.c:910: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast ./.libs/lt-suite.c: In function 'lt_update_lib_path': ./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str' makes pointer from integer without a cast arm-mingw32ce-strip: './suite.exe': No such file About the errno problem, I've sent a mail about that. There is also a problem with Windows CE: there is no environment variables in that OS, hence no getenv / setenv functions. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. I have run manually the commands of func_win32_libid(): $OBJDUMP -f libws2.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: duewbt.o: file format pe-arm-wince-little architecture: armv4, flags 0x0038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x duewbh.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: But grep is used to check i386, and not arm-wince-little. Please post the output of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A \ /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q Here is the result of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q [beginning] /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: __libws2_a_iname I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$2 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: __libws2_a_iname U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: _head_libws2_a I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: fthunk i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: hname i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: __imp_socket I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: socket T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: __imp_shutdown I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: shutdown T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib
Re: problem when cross compiling with mingw32ce
Hey, * Vincent Torri wrote on Fri, Oct 03, 2008 at 08:52:54AM CEST: I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** 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 libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.a This should only happen if the logic in libtool cannot determine that libws2.a is an import library. The logic for this is quite involved: it uses 'file' to determine the file type, and may use the func_win32_libid shell function in libtool, which itself uses $NM and $OBJDUMP to find out more. So you have to have these set correctly to the cross tools (arm-mingw32ce-objdump or so), for example. Normally, the configure script should get that right (please check that!). I have verified, and the names are correct (even in the libtool script: OBJDUMP=arm-mingw32ce-objdump NM=/home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B ) If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. I have run manually the commands of func_win32_libid(): file -L libws2.a: /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: current ar archive $OBJDUMP -f libws2.a | sed -e '10q' | /bin/grep -E 'file format pe-i386(.*architecture: i386)?' returns nothing. But: $OBJDUMP -f libws2.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: duewbt.o: file format pe-arm-wince-little architecture: armv4, flags 0x0038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x duewbh.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: But grep is used to check i386, and not arm-wince-little. I think that the problem is here. But I have no idea on how to fix it. What is even more strange is that there is no problem with the cegcc toolchain. There should be the same problem as the library is also an arm one. Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. I have run manually the commands of func_win32_libid(): $OBJDUMP -f libws2.a | sed -e '10q' In archive /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a: duewbt.o: file format pe-arm-wince-little architecture: armv4, flags 0x0038: HAS_DEBUG, HAS_SYMS, HAS_LOCALS start address 0x duewbh.o: file format pe-arm-wince-little architecture: armv4, flags 0x0039: But grep is used to check i386, and not arm-wince-little. Please post the output of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A \ /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q Here is the result of /home/torri/local/opt/mingw32ce/bin/arm-mingw32ce-nm -B -f posix -A /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a | sed 100q [beginning] /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbt.o]: __libws2_a_iname I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$2 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: __libws2_a_iname U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: _head_libws2_a I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: fthunk i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbh.o]: hname i 0004 /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: __imp_socket I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00078.o]: socket T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$5 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$6 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .idata$7 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: .text t /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: __imp_shutdown I /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: _head_libws2_a U /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00077.o]: shutdown T /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .bss b /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .data d /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib/libws2.a[duewbs00076.o]: .idata$4 i /home/torri/local/opt/mingw32ce/arm-mingw32ce/lib
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. about that function, the results mentions 'x86 archive *', same when it's a dll or executable. Is it a problem ? Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
On Sun, 5 Oct 2008, Vincent Torri wrote: On Sun, 5 Oct 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST: If with those settings, things still fail, you should surround the func_win32_libid code in your libtool script with 'set -x', 'set +x' and look at the commands called, when 'libtool --mode=link' is run. Call them manually and inspect their output. The comments in the function explain what is expected. about that function, the results mentions 'x86 archive *', same when it's a dll or executable. Is it a problem ? more precisely, with mingw32ce: * for DLL, win32_fileres is: $ file -L .libs/libevil-0.dll .libs/libevil-0.dll: MS-DOS executable PE for MS Windows (DLL) 32-bit so it is good enough * for executable, win32_fileres is: $ file -L ../bin/.libs/suite.exe ../bin/.libs/suite.exe: MS-DOS executable PE for MS Windows 32-bit so it is not enough. I think that a case should be added. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** 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 libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.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. I pass -no-undefined. The command line is: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil.lo libevil_la-evil_fcntl.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lws2 Does someone know why ? 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. I've never seen those message. Again, I would like to know what is happening. No idea where I should look in ltmain.sh to fix those messages ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: using .la or .a when linking an executable ?
Hey, Sorry, Ralf, i've just deleted your answer. It was embedded in a lot of spams... I paste it below. Hello Vincent, * Vincent Torri wrote on Sun, Sep 28, 2008 at 01:04:44PM CEST: eet_LDADD = $(top_builddir)/src/lib/libeet.la Hence when I call objdump -p on my eet binary, i get: NEEDED libeet.so.1 NEEDED libz.so.1 NEEDED libjpeg.so.62 But a friend told me that the eet binary should not have libz and libjpeg, only libeet. On many modern systems it is not necessary to link against indirect dependencies. 1) Is my friend right ? Partly. 2) If he is right, what should I do to remove those dependencies ? (flag to pass in a variable in my Makefile.am, or something like that) You can pass -Wl,--as-needed when the linker is the GNU binutils one. But beware that it may break things with some compilers (notably C++ ones), with some apps that do dlopen and expect dependencies to be present, and did not work right in some older versions of ld. Do you have an idea if: * it works on Windows (mingw binutils) ? * from which version of ld it is safe to use that flag ? I tried and with my binutils (linux for now), it works (at least objdump does not report other dependencies, i've not tried yet the program) eet_LDADD = $(top_builddir)/src/lib/libeet.la eet_DEPENDENCIES = $(top_builddir)/src/lib/libeet.la The last line is not needed, automake can infer that from the one above. Indeed :) I learn autotools things every days :) Now I have to clean all our libs and our main programs... thank you very much Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: using .la or .a when linking an executable ?
On Mon, 29 Sep 2008, Ralf Wildenhues wrote: * Vincent Torri wrote on Mon, Sep 29, 2008 at 09:47:02PM CEST: * Ralf Wildenhues wrote: * Vincent Torri wrote on Sun, Sep 28, 2008 at 01:04:44PM CEST: 2) If he is right, what should I do to remove those dependencies ? (flag to pass in a variable in my Makefile.am, or something like that) You can pass -Wl,--as-needed when the linker is the GNU binutils one. But beware that it may break things with some compilers (notably C++ ones), with some apps that do dlopen and expect dependencies to be present, and did not work right in some older versions of ld. Do you have an idea if: * it works on Windows (mingw binutils) ? No. I wouldn't even know that indirect deps work on w32, or whether they help there. Ok, i'll wait for a mingw dev to answer. * from which version of ld it is safe to use that flag ? Look at the gnulib module lib-ignore, for a pointer for more information, and a macro to use --as-needed when possible. for posterity: according to NEWS of ld, it as been introduced in binutils 2.15 (mid 2004) Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** 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 libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.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. I pass -no-undefined. The command line is: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil.lo libevil_la-evil_fcntl.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lws2 Does someone know why ? 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. I've never seen those message. Again, I would like to know what is happening. No idea where I should look to fix those messages ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
problem when cross compiling with mingw32ce
Hey, I'm cross-compiling using the cegcc toolchain and the mingw32ce compiler. I have 2 problems: 1) I use Windows sockets, hence i have to link against libws2 and I pass -lws2. I have the following (usual...) message: *** Warning: linker path does not have real file for library -lws2. *** 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 libws2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.1.0/../../../../arm-mingw32ce/lib//libws2.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. I pass -no-undefined. The command line is: /bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0 -L/home/torri/local/wince/lib -L/home/torri/local/opt/cegcc/lib -o libevil.la -rpath /home/torri/local/wince/lib libevil_la-evil.lo libevil_la-evil_fcntl.lo libevil_la-evil_langinfo.lo libevil_la-evil_mman.lo libevil_la-evil_pwd.lo libevil_la-evil_stdlib.lo libevil_la-evil_unistd.lo libevil_la-evil_util.lo -lws2 Does someone know why ? 2) 2nd qestion: I have the following message from libtool (which i do not have with other compilers): libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/wince/bin' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/lib' libtool: link: Continuing, but uninstalled executables may not work. libtool: link: Could not determine host path corresponding to libtool: link: '/home/torri/local/opt/cegcc/bin' libtool: link: Continuing, but uninstalled executables may not work. I've never seen those message. Again, I would like to know what is happening. thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: .gcno files removed from .libs directory
Hey, * Vincent Torri wrote on Fri, Aug 29, 2008 at 05:38:59PM CEST: I'm compiling two libraries with the options -fprofile-arcs -ftest-coverage passed to gcc. The first one has .gcno files in his directory and the .libs sub directory. The second one has .gcno files in his directory but not in the .libs subdir. I paste below the Makefile.am of eash lib: there is a difference in the creation of the libs. libtool explicitely removes the .gcno files in the 2nd case: libtool: link: rm -fr .libs/eina_chained_mempool.gcno Confirmed. The patch below should fix it. It still needs a test. I have tried the patch and it works well :) thank you Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: .gcno files removed from .libs directory
On Sun, 31 Aug 2008, Ralf Wildenhues wrote: Hello Vincent, Thanks for the bug report. * Vincent Torri wrote on Fri, Aug 29, 2008 at 05:38:59PM CEST: I'm compiling two libraries with the options -fprofile-arcs -ftest-coverage passed to gcc. The first one has .gcno files in his directory and the .libs sub directory. The second one has .gcno files in his directory but not in the .libs subdir. I paste below the Makefile.am of eash lib: [...] clean-local: @rm -rf *.gcno BTW, why the '@' here? There's nothing wrong with showing this command (but of course it doesn't matter much either). I agree, it even be usefull to see such commands there is a difference in the creation of the libs. libtool explicitely removes the .gcno files in the 2nd case: libtool: link: rm -fr .libs/eina_chained_mempool.gcno does someone know why libtool remove the .gcno files. Not yet, but it does sound like a bug (in either Libtool or Autoconf). You could really help us find this bug more easily by trying to reduce this to a small example package that exposes the issue for you, and show how exactly you configured and built the package. The files configure.ac, Makefile.am, and one library source file, should probably be sufficient. If that's too much work for you, then please at least post how you configured and built the second package (all command lines plus all of their output), and also post config.log. Please gzip large files, thank you. for the source code: see the attached file autotools.tar.bz2 for the configuration: autoreconf -f -i ./configure make for the output : output.log.bz2 for config.log : config.log.bz2 BTW, which Libtool and Autoconf versions do you use? autoconf 2.62 libtool 2.2.5a for libtool, it's a git version that I have grabbed just after cegcc was added. thanks Vincent Torri PS: if you note things that are wrong in configure.ac, please don't hesitate to tell me. output.log.bz2 Description: Binary data config.log.bz2 Description: Binary data autotools.tar.bz2 Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
.gcno files removed from .libs directory
Hey I'm compiling two libraries with the options -fprofile-arcs -ftest-coverage passed to gcc. The first one has .gcno files in his directory and the .libs sub directory. The second one has .gcno files in his directory but not in the .libs subdir. I paste below the Makefile.am of eash lib: * First lib (which works) MAINTAINERCLEANFILES = Makefile.in AM_CPPFLAGS = \ -I$(top_srcdir)/src/include \ -DPACKAGE_BIN_DIR=\$(bindir)\ \ -DPACKAGE_LIB_DIR=\$(libdir)\ \ -DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\ \ @COVERAGE_CFLAGS@ lib_LTLIBRARIES = libeina.la libeina_la_SOURCES = \ eina_error.c \ eina_hash.c \ eina_lalloc.c \ eina_inlist.c \ eina_file.c \ eina_mempool.c \ eina_list.c \ eina_module.c \ eina_value.c \ eina_array.c \ eina_magic.c \ eina_main.c \ eina_counter.c \ eina_iterator.c \ eina_accessor.c \ eina_convert.c \ eina_rbtree.c \ eina_stringshare.c libeina_la_LIBADD = -ldl -lrt @COVERAGE_LIBS@ -lm libeina_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ libeina_la_DEPENDENCIES = $(top_builddir)/config.h clean-local: @rm -rf *.gcno * Second lib (which does not work): MAINTAINERCLEANFILES = Makefile.in AM_CPPFLAGS = \ -I. \ -I$(top_srcdir)/src/include \ @COVERAGE_CFLAGS@ controllerdir = $(libdir)/eina/chained_pool/ controller_LTLIBRARIES = eina_chained_mempool.la eina_chained_mempool_la_SOURCES = \ eina_chained_mempool.c eina_chained_mempool_la_LIBADD = $(top_builddir)/src/lib/libeina.la @COVERAGE_LIBS@ eina_chained_mempool_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -module -avoid-version eina_chained_mempool_la_DEPENDENCIES = $(top_builddir)/src/lib/libeina.la clean-local: @rm -rf *.gcno there is a difference in the creation of the libs. libtool explicitely removes the .gcno files in the 2nd case: libtool: link: rm -fr .libs/eina_chained_mempool.gcno does someone know why libtool remove the .gcno files. And of course, does someone know a way to keep those files ? thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Separate CPPFLAGS for static and shared libs
On Wed, 4 Jun 2008, Ralf Wildenhues wrote: * Vikram Ambrose wrote on Wed, Jun 04, 2008 at 03:54:35PM CEST: However I need to pass separate CPPFLAGS to the objects destined for the shared library as opposed to the objects destined for the library archive. As Andreas already replied, just use #ifdef PIC for shared and #ifndef PIC for static code. That usually works. I think that it will not work with MinGW. But then you can use DLL_EXPORT. Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
