public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* libtool: link: object name conflicts in archive
@ 2014-04-15  7:22 Gisela Haschmich
  2014-04-15  9:31 ` Corinna Vinschen
  0 siblings, 1 reply; 12+ messages in thread
From: Gisela Haschmich @ 2014-04-15  7:22 UTC (permalink / raw)
  To: cygwin


Hello,

i tried to compile MBDyn 1.5.5 with cygwin and got an error "libtool: link: object name conflicts in archive". I used the same for 1.5.0 and it worked.


make[2]: Entering directory '/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap'
/bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O2   -o libmbwrap.la  harwout.lo harwout_.lo harwrap.lo kluwrap.lo lapackwrap.lo linsol.lo mschwrap.lo naivewrap.lo parnaivewrap.lo parsuperluwrap.lo superluwrap.lo umfpackwrap.lo taucswrap.lo y12wrap.lo wsmpwrap.lo   ../libmbmath/libmbmath.la ../libmbutil/libmbutil.la ../libobjs/libobjs.la ../libcolamd/libmbdyncolamd.la ../libnaive/libnaive.la /home/ntmoe/mbdyn-1.5.5/libraries/liby12/liby12.la -lm -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath
-lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl
libtool: link: rm -fr  .libs/libmbwrap.lax
libtool: link: (cd .libs/libmbwrap.lax/libmbmath.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libmbmath/.libs/libmbmath.lib")
libtool: link: (cd .libs/libmbwrap.lax/libmbutil.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libmbutil/.libs/libmbutil.lib")
libtool: link: (cd .libs/libmbwrap.lax/libobjs.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libobjs/.libs/libobjs.lib")
libtool: link: (cd .libs/libmbwrap.lax/libmbdyncolamd.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libcolamd/.libs/libmbdyncolamd.lib")
libtool: link: (cd .libs/libmbwrap.lax/libnaive.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libnaive/.libs/libnaive.lib")
libtool: link: (cd .libs/libmbwrap.lax/liby12.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib")
libtool: link: object name conflicts in archive: .libs/libmbwrap.lax/liby12.lib//home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib
Makefile:458: recipe for target 'libmbwrap.la' failed
make[2]: *** [libmbwrap.la] Error 1
make[2]: Leaving directory '/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap'
Makefile:344: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ntmoe/mbdyn-1.5.5/libraries'
Makefile:448: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

i found with google, that it could be an error with path variable, because it needs lib.exe from Visual Studio. I changed it to minimal, but i have still the same error

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/bin:/cygdrive/C/Users/velten.spaegele/Documents/VisualStudio8/Common7/IDE:/cygdrive/C/Users/velten.spaegele/Documents/VisualStudio8/VC/BIN



so what do i wrong ?




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-15  7:22 libtool: link: object name conflicts in archive Gisela Haschmich
@ 2014-04-15  9:31 ` Corinna Vinschen
  2014-04-15 11:16   ` Gisela Haschmich
  0 siblings, 1 reply; 12+ messages in thread
From: Corinna Vinschen @ 2014-04-15  9:31 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 3439 bytes --]

On Apr 15 07:22, Gisela Haschmich wrote:
> 
> Hello,
> 
> i tried to compile MBDyn 1.5.5 with cygwin and got an error "libtool: link: object name conflicts in archive". I used the same for 1.5.0 and it worked.
> 
> 
> make[2]: Entering directory '/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap'
> /bin/sh ../../libtool --tag=CXX   --mode=link g++  -g -O2   -o libmbwrap.la  harwout.lo harwout_.lo harwrap.lo kluwrap.lo lapackwrap.lo linsol.lo mschwrap.lo naivewrap.lo parnaivewrap.lo parsuperluwrap.lo superluwrap.lo umfpackwrap.lo taucswrap.lo y12wrap.lo wsmpwrap.lo   ../libmbmath/libmbmath.la ../libmbutil/libmbutil.la ../libobjs/libobjs.la ../libcolamd/libmbdyncolamd.la ../libnaive/libnaive.la /home/ntmoe/mbdyn-1.5.5/libraries/liby12/liby12.la -lm -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath
> -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl
> libtool: link: rm -fr  .libs/libmbwrap.lax
> libtool: link: (cd .libs/libmbwrap.lax/libmbmath.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libmbmath/.libs/libmbmath.lib")
> libtool: link: (cd .libs/libmbwrap.lax/libmbutil.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libmbutil/.libs/libmbutil.lib")
> libtool: link: (cd .libs/libmbwrap.lax/libobjs.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libobjs/.libs/libobjs.lib")
> libtool: link: (cd .libs/libmbwrap.lax/libmbdyncolamd.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libcolamd/.libs/libmbdyncolamd.lib")
> libtool: link: (cd .libs/libmbwrap.lax/libnaive.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap/../libnaive/.libs/libnaive.lib")
> libtool: link: (cd .libs/libmbwrap.lax/liby12.lib && ar x "/home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib")
> libtool: link: object name conflicts in archive: .libs/libmbwrap.lax/liby12.lib//home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib
> Makefile:458: recipe for target 'libmbwrap.la' failed
> make[2]: *** [libmbwrap.la] Error 1
> make[2]: Leaving directory '/home/ntmoe/mbdyn-1.5.5/libraries/libmbwrap'
> Makefile:344: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/ntmoe/mbdyn-1.5.5/libraries'
> Makefile:448: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
> 
> i found with google, that it could be an error with path variable, because it needs lib.exe from Visual Studio. I changed it to minimal, but i have still the same error

No, it doesn't.  Libtool calls gcc, it never tries to use VS tools.
This looks like a problem earlier in the build.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: libtool: link: object name conflicts in archive
  2014-04-15  9:31 ` Corinna Vinschen
@ 2014-04-15 11:16   ` Gisela Haschmich
  2014-04-15 11:28     ` Corinna Vinschen
  0 siblings, 1 reply; 12+ messages in thread
From: Gisela Haschmich @ 2014-04-15 11:16 UTC (permalink / raw)
  To: cygwin




> >
> > Hello,
> >
> > i tried to compile MBDyn 1.5.5 with cygwin and got an error "libtool:
> link: object name conflicts in archive". I used the same for 1.5.0 and
> it worked.
> >

> > libtool: link: object name conflicts in archive: .libs/libmbwrap.lax/liby12.lib//home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib

> >
> > i found with google, that it could be an error with path variable, because
> it needs lib.exe from Visual Studio. I changed it to minimal, but i have
> still the same error
>
> No, it doesn't.  Libtool calls gcc, it never tries to use VS tools.
> This looks like a problem earlier in the build.
>
and whats about lib.exe, do i need the path to VS tools lib.exe or what should use instead ?



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: libtool: link: object name conflicts in archive
  2014-04-15 11:16   ` Gisela Haschmich
@ 2014-04-15 11:28     ` Corinna Vinschen
  2014-04-15 23:53       ` Peter Rosin
  0 siblings, 1 reply; 12+ messages in thread
From: Corinna Vinschen @ 2014-04-15 11:28 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Apr 15 11:16, Gisela Haschmich wrote:
> > > Hello,
> > >
> > > i tried to compile MBDyn 1.5.5 with cygwin and got an error "libtool:
> > link: object name conflicts in archive". I used the same for 1.5.0 and
> > it worked.
> > >
> 
> > > libtool: link: object name conflicts in archive: .libs/libmbwrap.lax/liby12.lib//home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib
> 
> > >
> > > i found with google, that it could be an error with path variable, because
> > it needs lib.exe from Visual Studio. I changed it to minimal, but i have
> > still the same error
> >
> > No, it doesn't.  Libtool calls gcc, it never tries to use VS tools.
> > This looks like a problem earlier in the build.
> >
> and whats about lib.exe, do i need the path to VS tools lib.exe or what should use instead ?

gcc uses ld from binutils.  There's really no reason to have any VC tool
in the path.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-15 11:28     ` Corinna Vinschen
@ 2014-04-15 23:53       ` Peter Rosin
  2014-04-16  7:21         ` Gisela Haschmich
  0 siblings, 1 reply; 12+ messages in thread
From: Peter Rosin @ 2014-04-15 23:53 UTC (permalink / raw)
  To: cygwin

On 2014-04-15 13:27, Corinna Vinschen wrote:
> On Apr 15 11:16, Gisela Haschmich wrote:
>>>> Hello,
>>>>
>>>> i tried to compile MBDyn 1.5.5 with cygwin and got an error "libtool:
>>> link: object name conflicts in archive". I used the same for 1.5.0 and
>>> it worked.
>>>>
>>
>>>> libtool: link: object name conflicts in archive: .libs/libmbwrap.lax/liby12.lib//home/ntmoe/mbdyn-1.5.5/libraries/liby12/.libs/liby12.lib
>>
>>>>
>>>> i found with google, that it could be an error with path variable, because
>>> it needs lib.exe from Visual Studio. I changed it to minimal, but i have
>>> still the same error
>>>
>>> No, it doesn't.  Libtool calls gcc, it never tries to use VS tools.
>>> This looks like a problem earlier in the build.
>>>
>> and whats about lib.exe, do i need the path to VS tools lib.exe or what should use instead ?
> 
> gcc uses ld from binutils.  There's really no reason to have any VC tool
> in the path.

Side note, the GNU "equivalent" of MS lib.exe is ar. (ld corresponds to
MS link.exe).

Regarding the issue, it is a bad sign that the archives are named libmbmath.lib,
libmbutil.lib etc. For a Cygwin build, you want them named libmbmath.a. The
.lib suffix is a clear indicator of a problem earlier in the build, just
like Corinna said. Is the Cygwin binutils package installed properly? I
imagine something like this could happen if the binutils install is broken
and the Microsoft tools are on $PATH (but I haven't tested that).

Cheers,
Peter


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: libtool: link: object name conflicts in archive
  2014-04-15 23:53       ` Peter Rosin
@ 2014-04-16  7:21         ` Gisela Haschmich
  2014-04-16  8:03           ` Corinna Vinschen
                             ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Gisela Haschmich @ 2014-04-16  7:21 UTC (permalink / raw)
  To: cygwin


> Side note, the GNU "equivalent" of MS lib.exe is ar. (ld corresponds
> to MS link.exe).
>
> Regarding the issue, it is a bad sign that the archives are named libmbmath.lib,
>
> libmbutil.lib etc. For a Cygwin build, you want them named libmbmath.a. The
> .lib suffix is a clear indicator of a problem earlier in the build, just
> like Corinna said. Is the Cygwin binutils package installed properly? I
> imagine something like this could happen if the binutils install is broken
> and the Microsoft tools are on $PATH (but I haven't tested that).


I tried it now with

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/lib/lapack

and got lib: command not found

/bin/sh ../../libtool --tag=F77   --mode=link gfortran     -o liby12.la  y12mae.lo y12maf.lo y12mbe.lo y12mbf.lo y12mce.lo y12mcf.lo y12mde.lo y12mdf.lo y12mfe.lo y12mge.lo y12mhe.lo -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32
-lshell32 -luser32 -lkernel32 -lltdl
libtool: link: lib -OUT:.libs/liby12.lib .libs/y12mae.o .libs/y12maf.o .libs/y12mbe.o .libs/y12mbf.o .libs/y12mce.o .libs/y12mcf.o .libs/y12mde.o .libs/y12mdf.o .libs/y12mfe.o .libs/y12mge.o .libs/y12mhe.o
../../libtool: line 1117: lib: command not found




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Re: libtool: link: object name conflicts in archive
  2014-04-16  7:21         ` Gisela Haschmich
@ 2014-04-16  8:03           ` Corinna Vinschen
  2014-04-16 12:07             ` tednolan
  2014-04-16  9:34           ` Peter Rosin
  2014-04-17  8:46           ` szgyg
  2 siblings, 1 reply; 12+ messages in thread
From: Corinna Vinschen @ 2014-04-16  8:03 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

On Apr 16 07:21, Gisela Haschmich wrote:
> 
> > Side note, the GNU "equivalent" of MS lib.exe is ar. (ld corresponds
> > to MS link.exe).
> >
> > Regarding the issue, it is a bad sign that the archives are named libmbmath.lib,
> >
> > libmbutil.lib etc. For a Cygwin build, you want them named libmbmath.a. The
> > .lib suffix is a clear indicator of a problem earlier in the build, just
> > like Corinna said. Is the Cygwin binutils package installed properly? I
> > imagine something like this could happen if the binutils install is broken
> > and the Microsoft tools are on $PATH (but I haven't tested that).
> 
> 
> I tried it now with
> 
> $ echo $PATH
> /usr/local/bin:/usr/bin:/usr/lib/lapack
> 
> and got lib: command not found
> 
> /bin/sh ../../libtool --tag=F77   --mode=link gfortran     -o liby12.la  y12mae.lo y12maf.lo y12mbe.lo y12mbf.lo y12mce.lo y12mcf.lo y12mde.lo y12mdf.lo y12mfe.lo y12mge.lo y12mhe.lo -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32
> -lshell32 -luser32 -lkernel32 -lltdl
> libtool: link: lib -OUT:.libs/liby12.lib .libs/y12mae.o .libs/y12maf.o .libs/y12mbe.o .libs/y12mbf.o .libs/y12mce.o .libs/y12mcf.o .libs/y12mde.o .libs/y12mdf.o .libs/y12mfe.o .libs/y12mge.o .libs/y12mhe.o
> ../../libtool: line 1117: lib: command not found

This is *so* wrong.  That's very likely a problem in the configury then,
and you should try to find out how configure gets the idea to use a tool
called "lib".  How did you run configure?  This might be a result of
using wrong arguments.  Also, the upstream devs might have an idea why
the build process tries to use MS tools when building for Cygwin.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-16  7:21         ` Gisela Haschmich
  2014-04-16  8:03           ` Corinna Vinschen
@ 2014-04-16  9:34           ` Peter Rosin
  2014-04-17  8:46           ` szgyg
  2 siblings, 0 replies; 12+ messages in thread
From: Peter Rosin @ 2014-04-16  9:34 UTC (permalink / raw)
  To: cygwin

On 2014-04-16 09:21, Gisela Haschmich wrote:
> 
>> Side note, the GNU "equivalent" of MS lib.exe is ar. (ld corresponds
>> to MS link.exe).
>>
>> Regarding the issue, it is a bad sign that the archives are named libmbmath.lib,
>>
>> libmbutil.lib etc. For a Cygwin build, you want them named libmbmath.a. The
>> .lib suffix is a clear indicator of a problem earlier in the build, just
>> like Corinna said. Is the Cygwin binutils package installed properly? I
>> imagine something like this could happen if the binutils install is broken
>> and the Microsoft tools are on $PATH (but I haven't tested that).
> 
> 
> I tried it now with
> 
> $ echo $PATH
> /usr/local/bin:/usr/bin:/usr/lib/lapack
> 
> and got lib: command not found
> 
> /bin/sh ../../libtool --tag=F77   --mode=link gfortran     -o liby12.la  y12mae.lo y12maf.lo y12mbe.lo y12mbf.lo y12mce.lo y12mcf.lo y12mde.lo y12mdf.lo y12mfe.lo y12mge.lo y12mhe.lo -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32
> -lshell32 -luser32 -lkernel32 -lltdl
> libtool: link: lib -OUT:.libs/liby12.lib .libs/y12mae.o .libs/y12maf.o .libs/y12mbe.o .libs/y12mbf.o .libs/y12mce.o .libs/y12mcf.o .libs/y12mde.o .libs/y12mdf.o .libs/y12mfe.o .libs/y12mge.o .libs/y12mhe.o
> ../../libtool: line 1117: lib: command not found

Did you really rerun configure with the new $PATH? You also need to kill
any configure cache, i.e. if you have one.

Cheers,
Peter


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-16  8:03           ` Corinna Vinschen
@ 2014-04-16 12:07             ` tednolan
  2014-04-16 13:59               ` Corinna Vinschen
  0 siblings, 1 reply; 12+ messages in thread
From: tednolan @ 2014-04-16 12:07 UTC (permalink / raw)
  To: cygwin

In message <20140416080331.GN3271@calimero.vinschen.de>you write:
>--KC+fneiph5CALyUl
>Content-Type: text/plain; charset=utf-8
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>> ../../libtool: line 1117: lib: command not found
>
>This is *so* wrong.  That's very likely a problem in the configury then,
>and you should try to find out how configure gets the idea to use a tool
>called "lib".  How did you run configure?  This might be a result of
>using wrong arguments.  Also, the upstream devs might have an idea why
>the build process tries to use MS tools when building for Cygwin.
>
>
>Corinna
>

I have run into a couple of "configure" scripts that when they see you
are running cygwin think that means they should try to build a native
Windows version rather than follow the linux-like path to a "native
Cygwin" version..

It's very irritating.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-16 12:07             ` tednolan
@ 2014-04-16 13:59               ` Corinna Vinschen
  0 siblings, 0 replies; 12+ messages in thread
From: Corinna Vinschen @ 2014-04-16 13:59 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

On Apr 16 07:35, tednolan@bellsouth.net wrote:
> In message <20140416080331.GN3271@calimero.vinschen.de>you write:
> >--KC+fneiph5CALyUl
> >Content-Type: text/plain; charset=utf-8
> >Content-Disposition: inline
> >Content-Transfer-Encoding: quoted-printable
> >> ../../libtool: line 1117: lib: command not found
> >
> >This is *so* wrong.  That's very likely a problem in the configury then,
> >and you should try to find out how configure gets the idea to use a tool
> >called "lib".  How did you run configure?  This might be a result of
> >using wrong arguments.  Also, the upstream devs might have an idea why
> >the build process tries to use MS tools when building for Cygwin.
> >
> >
> >Corinna
> >
> 
> I have run into a couple of "configure" scripts that when they see you
> are running cygwin think that means they should try to build a native
> Windows version rather than follow the linux-like path to a "native
> Cygwin" version..
> 
> It's very irritating.

Indeed.  It's not as bad anymore as 10 years ago, but there are still
packages out there who don't understand that Cygwin is not just a
frontend to build native Windows stuff.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-16  7:21         ` Gisela Haschmich
  2014-04-16  8:03           ` Corinna Vinschen
  2014-04-16  9:34           ` Peter Rosin
@ 2014-04-17  8:46           ` szgyg
  2014-04-17  9:57             ` Peter Rosin
  2 siblings, 1 reply; 12+ messages in thread
From: szgyg @ 2014-04-17  8:46 UTC (permalink / raw)
  To: cygwin

On 4/16/2014 9:21 AM, Gisela Haschmich wrote:
>
> /bin/sh ../../libtool --tag=F77   --mode=link gfortran     -o liby12.la  y12mae.lo y12maf.lo y12mbe.lo y12mbf.lo y12mce.lo y12mcf.lo y12mde.lo y12mdf.lo y12mfe.lo y12mge.lo y12mhe.lo -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/li
>   b/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32
> -lshell32 -luser32 -lkernel32 -lltdl
> libtool: link: lib -OUT:.libs/liby12.lib .libs/y12mae.o .libs/y12maf.o .libs/y12mbe.o .libs/y12mbf.o .libs/y12mce.o .libs/y12mcf.o .libs/y12mde.o .libs/y12mdf.o .libs/y12mfe.o .libs/y12mge.o .libs/y12mhe.o
> ../../libtool: line 1117: lib: command not found

After running configure there is a file named libtool in the source 
directory. Replace it with libtool from /bin, then run make. (You may 
need to install the libtool package in cygwin's setup.)

They have this in configure.in:
-----
if test "x$FC" = "x" ; then
         AC_PROG_F77
         if test "x$F77" = "x" ; then
                 AC_MSG_ERROR([Need a working Fortran compiler])
         fi
         AC_F77_LIBRARY_LDFLAGS
         LIBS="$LIBS $F77LIBS"
else
         F77="$FC"
         F77LIBS="$FCLIBS"
         LIBS="$LIBS $FCLIBS"
fi
-----
so libtool thinks it's F77 but not G77 and tries to use the native linker.

s


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: libtool: link: object name conflicts in archive
  2014-04-17  8:46           ` szgyg
@ 2014-04-17  9:57             ` Peter Rosin
  0 siblings, 0 replies; 12+ messages in thread
From: Peter Rosin @ 2014-04-17  9:57 UTC (permalink / raw)
  To: cygwin

On 2014-04-17 10:46, szgyg wrote:
> On 4/16/2014 9:21 AM, Gisela Haschmich wrote:
>>
>> /bin/sh ../../libtool --tag=F77   --mode=link gfortran     -o liby12.la  y12mae.lo y12maf.lo y12mbe.lo y12mbf.lo y12mce.lo y12mcf.lo y12mde.lo y12mdf.lo y12mfe.lo y12mge.lo y12mhe.lo -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lltdl  -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../lib -L/lib/../lib -L/usr/li
>>   b/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../.. -lgfortran -lquadmath -lm -lcygwin -ladvapi32
>> -lshell32 -luser32 -lkernel32 -lltdl
>> libtool: link: lib -OUT:.libs/liby12.lib .libs/y12mae.o .libs/y12maf.o .libs/y12mbe.o .libs/y12mbf.o .libs/y12mce.o .libs/y12mcf.o .libs/y12mde.o .libs/y12mdf.o .libs/y12mfe.o .libs/y12mge.o .libs/y12mhe.o
>> ../../libtool: line 1117: lib: command not found
> 
> After running configure there is a file named libtool in the source directory. Replace it with libtool from /bin, then run make. (You may need to install the libtool package in cygwin's setup.)
> 
> They have this in configure.in:
> -----
> if test "x$FC" = "x" ; then
>         AC_PROG_F77
>         if test "x$F77" = "x" ; then
>                 AC_MSG_ERROR([Need a working Fortran compiler])
>         fi
>         AC_F77_LIBRARY_LDFLAGS
>         LIBS="$LIBS $F77LIBS"
> else
>         F77="$FC"
>         F77LIBS="$FCLIBS"
>         LIBS="$LIBS $FCLIBS"
> fi
> -----
> so libtool thinks it's F77 but not G77 and tries to use the native linker.

Ouch, that's just br0ken.

It would probably work better to move AC_PROG_F77 out of the if
as below, otherwise language support is added to Libtool since
it "sees" the AC_PROG_F77 macro, but Libtool then gets thoroughly
confused when the macro expansion is not executed.

AC_PROG_F77
if test "x$FC" = "x" ; then
	if test "x$F77" = "x" ; then
		AC_MSG_ERROR([Need a working Fortran compiler])
	fi
	AC_F77_LIBRARY_LDFLAGS
	LIBS="$LIBS $F77LIBS"
else
	F77="$FC"
	F77LIBS="$FCLIBS"
	LIBS="$LIBS $FCLIBS"
fi

Side note, I believe it's $FLIBS, not $F77LIBS. But it has been many years
since I used Fortran at all, and I have never used it with Autotools.

Cheers,
Peter



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2014-04-17  9:57 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-15  7:22 libtool: link: object name conflicts in archive Gisela Haschmich
2014-04-15  9:31 ` Corinna Vinschen
2014-04-15 11:16   ` Gisela Haschmich
2014-04-15 11:28     ` Corinna Vinschen
2014-04-15 23:53       ` Peter Rosin
2014-04-16  7:21         ` Gisela Haschmich
2014-04-16  8:03           ` Corinna Vinschen
2014-04-16 12:07             ` tednolan
2014-04-16 13:59               ` Corinna Vinschen
2014-04-16  9:34           ` Peter Rosin
2014-04-17  8:46           ` szgyg
2014-04-17  9:57             ` Peter Rosin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).