[patch #3686] Trivial patch to change sprintf to snprintf in libltdl

[anonymous]

Additional Item Attachment, patch #3686 (project libtool):

File name: bbrun.cSize:4 KB
bigbrother file to change


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: MSYS+MSVC for libtool branch-2-0, take 2

[Ralf Wildenhues]

Hi Peter,

I've tried your patch now, with cygwin and this version:

| Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
| Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

configured like: CC=cl CXX=cl.

Notes:

`link -LIB' can be a problem if the cygwin `link' (to create hard links)
comes before the win32 paths.  `LIB' works here.

`LIB -EXTRACT' needs Windows paths for lib and extraction directory.
With cygwin, `cygpath -w' works.  But the result needs to be properly
quoted for func_show_eval, if that is to be used.

After working around these, the next failure is when linking libltdl:

| libltdl_la-ltdl.obj : error LNK2019: unresolved external symbol 
_lt_libltdl_LTX_preloaded_symbols referenced in function _lt_dlinit.
| .libs/ltdl-6.dll : fatal error LNK1120: 1 unresolved externals

because that thing is called `_lt_ltdl_LTX_preloaded_symbols' now that
libname_spec changed.  This is probably a bug in our build which
hardwires 
  libltdl_la_CPPFLAGS = -DLTDLOPEN=libltdl
but OTOH I'm not convinced yet that the libname_spec change is correct.

The `mv' command in this line
| +  _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags 
`$ECHO "X$deplibs" | $Xsed -e '\''s/ -lc$//'\''` -link -dll~linknames=~mv 
.libs/${libname}`$ECHO "X${release}" | $Xsed -e +s/[.]/-/g`${versuffix}.lib 
.libs/${libname}.lib'

is also broken w.r.t lib name.

Other than that, the HEAD convenience archive tests pass with this.  :)
Libtool's legacy test suite does too much with absolute paths which
kills my path workaround (a symlink in /tmp to my real $HOME which has
spaces in its name).

How do I get sensible information about what's in a dll (except trying
to link against it)?  (I really know little about win32.)

Cheers,
Ralf

Re: Fortran 90/95 (FC) support

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Fri, Jun 10, 2005 at 12:24:00AM CEST:
>
> - `ifort -static' is falsely detected as broken, because it shows
>   link-warnings.

To put this into perspective:  

| $ cat a.f
|   program foo
|   end
| $ ifort -static -blabla -o a a.f
| ifort: Command line warning: ignoring unknown option '-blabla'
| /opt/intel_fc_80/lib/libifcore.a(for_open_proc.o)(.text+0x3826): In function 
`for__compute_filename':
| : warning: Using 'getpwnam' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
| /opt/intel_fc_80/lib/libifcore.a(for_open_proc.o)(.text+0x3909): In function 
`for__compute_filename':
| : warning: Using 'getpwuid' in statically linked applications requires at 
runtime the shared libraries from the glibc version used for linking
| $ echo $?
| 0

Frankly, this compiler suite just sucks.  It's the most prominent
(only?) set of compilers that both
 a) don't fail but only warn when given an option they don't recognize
 b) spit out a warning for linking a trivial example.

Naturally, regular linking against the shared libs does not fail nor
warn.  What should we do to distinguish here?
grep out '\(unknown\|unrecognized\) option'?  This would kill any other
compilers which warn only, but with a different message.
Just hardwire ifort -static here?  Or just ignore this false failure?

Regards,
Ralf

Re: _LT_COMPILER_OPTION/_LT_LINKER_OPTION/ sed fix

[Paolo Bonzini]

As detailedly explained in the comment above this change, `$ECHO' is not
necessary instead of `echo'.  Also, sed regex `?' is not portable (and
in fact not recognized by GNU sed 4.1.2), but \{0,1\} is.


? is plain wrong, since sed uses basic regular expressions.  No GNU sed 
ever recognized it; the unportable one is \? and the portable one is 
\{0,1\} as you wrote.


Paolo

PING**n (PR/19210, PR/21921, toplevel bootstrap)

[Paolo Bonzini]

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00464.html
PR/19210: Add -{f,W}unsafe-loop-optimizations

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00260.html
Always create target tools in the gcc directory, take 6
(4.1 stage 2 project, toplevel bootstrap)

I think I sent at least six pings each for these. ;-)

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00446.html
PR/21921: tsi_link_before crashes if the tsi is at the end of the container

Paolo

Re: PING**n (PR/19210, PR/21921, toplevel bootstrap)

[Ralf Wildenhues]

* Paolo Bonzini wrote on Fri, Jun 10, 2005 at 07:48:00PM CEST:
>
*snip gcc-patches pings*
> 
> I think I sent at least six pings each for these. ;-)

And they have exactly what to do with Libtool?  :-)

Cheers, and SCNR
Ralf

RE: MSYS+MSVC for libtool branch-2-0, take 2

[Peter Ekberg]

Ralf Wildenhues wrote:
> Hi Peter,
> 
> I've tried your patch now, with cygwin and this version:
> 
> | Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
> | Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
> 
> configured like: CC=cl CXX=cl.
> 
> Notes:
> 
> `link -LIB' can be a problem if the cygwin `link' (to create 
> hard links)
> comes before the win32 paths.  `LIB' works here.

I have a fix for that in the attached patch, where you can
override by setting MSLINK to the appropriate executable.
I decided to not use LINK, since link.exe looks in the
LINK veriable for extra options.

Should we therefore keep track of LINK? Maybe that's an
autoconf question?

(The same is true for the CL and _CL_ variables used in a
similar maner by cl.exe.)

I have the feeling that some of this work should perhaps
be in autoconf or automake, but I also have the feeling
that it is not as easy to warp the arguments as needed
to suit MSVC?

> `LIB -EXTRACT' needs Windows paths for lib and extraction directory.
> With cygwin, `cygpath -w' works.  But the result needs to be properly
> quoted for func_show_eval, if that is to be used.

On MSYS, the paths does not need to be converted. They are
automatically converted for arguments to executables outside
the MSYS tree or something like that (they are assumed to be
win32 executables expecting win32 paths).

> After working around these, the next failure is when linking libltdl:
> 
> | libltdl_la-ltdl.obj : error LNK2019: unresolved external 
> symbol _lt_libltdl_LTX_preloaded_symbols referenced in 
> function _lt_dlinit.
> | .libs/ltdl-6.dll : fatal error LNK1120: 1 unresolved externals

Haven't tried libltdl, I do not depend on it for the project
I'm targeting and I have a hard time bootstrapping libtool
so I haven't tried the testsuite myself.

Any chance of a more up-to-date -2-0 prerelease soon, so that
I can get a bootstrapped version for free? :-)

> because that thing is called `_lt_ltdl_LTX_preloaded_symbols' now that
> libname_spec changed.  This is probably a bug in our build which
> hardwires 
>   libltdl_la_CPPFLAGS = -DLTDLOPEN=libltdl
> but OTOH I'm not convinced yet that the libname_spec change 
> is correct.

I think I have convinced myself that changing libname_spec is
the right thing to do. I find that I can remove some of the really
ugly stuff from the patch when I do that.

> The `mv' command in this line
> | +  _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs 
> $compiler_flags `$ECHO "X$deplibs" | $Xsed -e '\''s/ 
> -lc$//'\''` -link -dll~linknames=~mv .libs/${libname}`$ECHO 
> "X${release}" | $Xsed -e +s/[.]/-/g`${versuffix}.lib 
> .libs/${libname}.lib'
> 
> is also broken w.r.t lib name.

I don't see what you mean here. It does what I intend it to do,
it renames the import lib to not have a version number. Why
is that a problem? It matches the content of the .la file.

> Other than that, the HEAD convenience archive tests pass with 
> this.  :)
> Libtool's legacy test suite does too much with absolute paths which
> kills my path workaround (a symlink in /tmp to my real $HOME which has
> spaces in its name).
> 
> How do I get sensible information about what's in a dll (except trying
> to link against it)?  (I really know little about win32.)

http://www.dependencywalker.com/ (aka depends.exe)
dumpbin.exe is a command line tool

Things that should probably be worked on:

- Install dlls in ../bin/foo.dll, just like they are for MinGW
  and Cygwin. The generated .la are wrong as is.

- Add paths given with -L to the LIB variable so that the linker
  actually sees them. This should be done after converting them
  to win32 paths, which is easy on Cygwin and harder on MSYS.

- libtool at some point thinks /mingw/bin/ld is the linker and
  uses that to deduce stuff, perhaps other configure checks are
  also a problematic, I haven't looked closely since it works
  for me.

Attached is the latest version of the patch.

Cheers,
Peter

(and thanks for the review)


msys_msvc-3.patch
Description: msys_msvc-3.patch