bug-libtool
[Top][All Lists]
Advanced

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

Re: msys/mingw warnings about string length and putenv absence with gcc


From: Charles Wilson
Subject: Re: msys/mingw warnings about string length and putenv absence with gcc -Wall -ansi
Date: Tue, 30 Dec 2008 15:57:22 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666

Chris Pickett wrote:
> Charles Wilson wrote:
>> Actually, I believe the OP's issues occur when compiling the libtool
>> exectable wrapper program, so it definitely involves libtool. The
>> problem(s) occur when the surrounding project is compiled using
>> non-default CFLAGS (like -ansi) -- these CFLAGS propagate to the
>> LTCOMPILE command used to build the (libtool-provided) cwrapper program.
>>
>> Problem #1 was fixed here:
>>
>> commit d34008adff36714b3a593da2377202df0d94bffe
>> Author: Charles Wilson
>> Date:   Fri Apr 25 21:08:04 2008 -0400
>>
>>     Ensure cwrapper compiles without warnings under -std=c99.
> 
> That looks like the fix for the previous bug I mentioned.  I already
> have this since I'm using 2.2.6a.  This new problem is C89.

Huh? The string length split is unconditional, so regardless of your
compile options the string lengths are now less than 4095. Unless the
C89 limit was smaller than the C99 limit?

Urk. Yes, it is. The C99 limit is 4095, the C89 limit is 509. Well, the
fix is ugly, but not hard. We just need
  func_emit_wrapper_part[1-N]
where N is bigger than 2. Probably around 9 or 10.

Another harder fix would be to automagically split the wrapper script
text into the desired number of chunks. Something like the following
pseudocode:

cat <<-EOF > $TMPFILE
all 4300 bytes of the script
EOF

chunk=1
bytes=0
chunksize=508
bytesleft=size of $TMPFILE
while bytesleft > 0
  byteswritten=$(\
     dd if=$TMPFILE of=$TMPFILE_chunk_$chunk bs=$chunksize \
         skip=$(( $chunksize * ($chunk - 1) )) 2>&1 |\
     awk '/bytes/{print $1}' )
  bytesleft=$(( $bytesleft - $byteswritten ))
  bytes=$(( bytes + $byteswritten ))
  $ECHO_N "const char* chunk_$chunk = \"\\"
  cat $$TMPFILE_chunk_$chunk | sed -e '$s/$/";/'
  chunk=$(( $chunk + 1 ))

followed by a similar loop so that the "print all chunks" C function
will actually print all the chunks.

However, this fix might die if the chunk boundary falls in the middle of
a digraph or trigraph like '\n'.  So, it's probably better to just do
the simple func_emit_wrapper_part[1-N] version.

> 
>> Problem #2
>>
>> +# ifdef __STRICT_ANSI__
>> +int putenv (char *);
>> +# endif

Yep, this will work [*], as all of -std=c89, -std=c99, and -ansi #defin
__STRICT_ANSI__ (gcc, anyway)


[*] Roumen is right, however: we are not using _MSC_VER as a proxy for
mingw. _MSC_VER is strictly for msvc -- and it looks like MSVC *always*
declares _putenv. What we want is this (the _putenv indirection for
mingw is in case the surrounding package -- or a new gcc -- turns off
libmoldnames):

 #ifdef _MSC_VER
 # include <direct.h>
 # include <process.h>
 # include <io.h>
 # define setmode _setmode
+# define putenv _putenv
 #else
 # include <unistd.h>
 # include <stdint.h>
+# ifdef __MINGW32__
+#  ifdef __STRICT_ANSI__
+int _putenv (const char *);
+define putenv _putenv
+#  endif
+# endif
 # ifdef __CYGWIN__
 #  include <io.h>
 #  define HAVE_SETENV
 #  ifdef __STRICT_ANSI__
 char *realpath (const char *, char *);
 int putenv (char *);
 int setenv (const char *, const char *, int);
 #  endif
 # endif
 #endif


Okay, this is looking more involved. I'll have to do the whole
regression thing...sigh.

--
Chuck




reply via email to

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