lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] libtool and _putenv


From: Greg Chicares
Subject: Re: [lmi] libtool and _putenv
Date: Mon, 25 Jan 2016 14:31:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2016-01-25 13:13, Vadim Zeitlin wrote:
> On Mon, 25 Jan 2016 03:59:29 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-01-25 03:30, Greg Chicares wrote:
> GC> [...]
> GC> > /usr/share/libtool/config[1]$ls
> GC> > compile  config.guess  config.sub  depcomp  install-sh  ltmain.sh  
> missing
> GC> > 
> GC> > No 'ltmain.m4sh'; is 'ltmain.sh' the same thing? (I find no 
> 'ltmain.m4sh'
> GC> > on either debian-7 or debian-8.)
> GC> > 
> GC> > /usr/share/libtool/config[0]$grep -A3 MINGW ltmain.sh
> GC> > #if defined(__MINGW32__)
> GC> > # ifdef __STRICT_ANSI__
> GC> > int _putenv (const char *);
> GC> > # endif
> GC> > 
> GC> > So I just patch that manually, right?
> 
>  Sorry, I should have been more explicit about this, this stuff is
> confusing because there are several steps leading to the generation of the
> final libtool script in the build directory of the project: first, there is
> the "libtoolize" step hidden inside the autogen.sh script, then there is
> automake (also there) and finally configure runs and generates the final
> libtool from the template created by autogen.sh.
> 
>  So to solve this problem once and for all you indeed need to edit the
> /usr/share/libtool/config/ltmain.sh file, but then you need to rerun
> autogen.sh (you could also rerun just libtoolize and automake manually, but
> the savings are not great enough to bother with this) and re-run configure
> (although normally this will be done automatically if you just run "make"
> again, automake-generated makefiles are smart like this). And once you do
> all this, it should work and you shouldn't have to worry about it again
> until at least the next system update.

But I thought I did that--from my original message:

| Will it work if I reconfigure? No:
|
| cd ~/src/lmi
| ./autogen.sh
| PATH=$HOME/msw/i686-w64-mingw32/bin:$PATH ~/src/lmi/configure \
|   --prefix=$HOME/msw/i686-w64-mingw32 --host=i686-w64-mingw32 \
|   CPPFLAGS=-I$HOME/msw/i686-w64-mingw32/include \
|   LDFLAGS=-L$HOME/msw/i686-w64-mingw32/lib \
|   CXXFLAGS='-Wno-unused-local-typedefs -Wno-unused-variable'
| cd  ~/build/lmi-msw
| make clean
| make

Let me try again, one step at a time.

>  you indeed need to edit the
> /usr/share/libtool/config/ltmain.sh file,

I think I had done that in a valid way, but let's take a look:

/home/greg[0]$diff -U3 /usr/share/libtool/config/ltmain.sh.original 
/usr/share/libtool/config/ltmain.sh
--- /usr/share/libtool/config/ltmain.sh.original        2016-01-25 
03:43:07.768000000 +0000
+++ /usr/share/libtool/config/ltmain.sh 2016-01-25 03:44:17.100000000 +0000
@@ -4178,7 +4178,8 @@
 /* declarations of non-ANSI functions */
 #if defined(__MINGW32__)
 # ifdef __STRICT_ANSI__
-int _putenv (const char *);
+     /* int _putenv (const char *); */
+_CRTIMP int _putenv (const char *);
 # endif
 #elif defined(__CYGWIN__)
 # ifdef __STRICT_ANSI__

> but then you need to rerun
> autogen.sh

/home/greg[0]$cd ~/src/lmi
/home/greg/src/lmi[0]$./autogen.sh
Setting up build system for lmi:
 - aclocal
 - libtoolize
 - autoconf
 - autoheader
 - automake
Makefile.am:464: warning: source file '$(top_builddir)/dummy.cpp' is in a 
subdirectory,
Makefile.am:464: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding 
output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same 
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
Build setup successful, type "configure" to configure lmi now.
/home/greg/src/lmi[0]$

> and re-run configure

/home/greg/src/lmi[0]$PATH=$HOME/msw/i686-w64-mingw32/bin:$PATH 
~/src/lmi/configure \
>   --prefix=$HOME/msw/i686-w64-mingw32 --host=i686-w64-mingw32 \
>   CPPFLAGS=-I$HOME/msw/i686-w64-mingw32/include \
>   LDFLAGS=-L$HOME/msw/i686-w64-mingw32/lib \
>   CXXFLAGS='-Wno-unused-local-typedefs -Wno-unused-variable'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
[...snip many lines that appear unremarkable...]
checking whether the C++ compiler accepts the -Wno-parentheses flag... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
/home/greg/src/lmi[0]$

> (although normally this will be done automatically if you just run "make"
> again, automake-generated makefiles are smart like this). And once you do
> all this, it should work and you shouldn't have to worry about it again
> until at least the next system update.

/home/greg/src/lmi[0]$cd  ~/build/lmi-msw
/home/greg/build/lmi-msw[0]$make clean
 cd . && /bin/bash ./config.status Makefile depfiles
config.status: creating Makefile
config.status: executing depfiles commands
 rm -f lmi_cli.exe lmi_wx.exe elapsed_time.exe generate_passkey.exe [...]
...
test -z "test-suite.log" || rm -f test-suite.log
rm -f *.lo
/home/greg/build/lmi-msw[0]$

And now:

/home/greg/build/lmi-msw[0]$make --quiet --jobs=8
  CXX      test_coding_rules-my_test_coding_rules.o
  CXX      test_coding_rules-sigfpe.o
...
./.libs/lt-wx_test.c:39:5: error: '_putenv' redeclared without dllimport 
attribute: previous dllimport ignored [-Werror=attributes]
 int _putenv (const char *);
     ^
cc1: all warnings being treated as errors
i686-w64-mingw32-strip: './wx_test.exe': No such file

Let's try that again without '--jobs=8' so that everything's in order:

/home/greg/build/lmi-msw[0]$make --quiet
  CXXLD    lmi_cli.exe
libtool: link: Could not determine the host path corresponding to
libtool: link:   `/home/greg/msw/i686-w64-mingw32/lib'
libtool: link: Continuing, but uninstalled executables may not work.
libtool: link: Could not determine the host path corresponding to
libtool: link:   
`/home/greg/msw/i686-w64-mingw32/lib:/home/greg/msw/i686-w64-mingw32/bin'
libtool: link: Continuing, but uninstalled executables may not work.
./.libs/lt-lmi_cli.c:39:5: error: '_putenv' redeclared without dllimport 
attribute: previous dllimport ignored [-Werror=attributes]
 int _putenv (const char *);
     ^
cc1: all warnings being treated as errors
i686-w64-mingw32-strip: './lmi_cli.exe': No such file

What am I missing?

In case this helps:

$uname -a
Linux debian8b 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) 
x86_64 GNU/Linux

/home/greg/build/lmi-msw[0]$grep MINGW -A5 ./.libs/lt-lmi_cli.c
#if defined(__MINGW32__)
# ifdef __STRICT_ANSI__
int _putenv (const char *);
# endif
#elif defined(__CYGWIN__)
# ifdef __STRICT_ANSI__
--
#elif defined(__MINGW32__)
# define setmode _setmode
# define stat    _stat
# define chmod   _chmod
# define getcwd  _getcwd
# define putenv  _putenv
/home/greg/build/lmi-msw[0]$grep MINGW -A5 /usr/share/libtool/config/ltmain.sh
#if defined(__MINGW32__)
# ifdef __STRICT_ANSI__
     /* int _putenv (const char *); */
_CRTIMP int _putenv (const char *);
# endif
#elif defined(__CYGWIN__)
--
#elif defined(__MINGW32__)
# define setmode _setmode
# define stat    _stat
# define chmod   _chmod
# define getcwd  _getcwd
# define putenv  _putenv
/home/greg/build/lmi-msw[0]$

The libtool stuff was regenerated--it's only a few minutes old:

/home/greg/build/lmi-msw[0]$ls -l ./.libs/lt-lmi_cli.c
-rw-r--r-- 1 greg greg 32737 Jan 25 14:22 ./.libs/lt-lmi_cli.c

but it looks like the changes to /usr/share/libtool/config/ltmain.sh
are still being ignored.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]