On 2013-09-17 10:23, Peter Rosin wrote:
> On 2013-09-17 09:50, Ozkan Sezer wrote:
>> Any chance that this patch, or a patch that fixes bug #15321 [1],
>> gets applied any time?
>
> Yes, I'll push it in a bit.
Pushed.
Cheers,
Peter
___
https://lists.g
On 2013-09-17 09:50, Ozkan Sezer wrote:
> Any chance that this patch, or a patch that fixes bug #15321 [1],
> gets applied any time?
Yes, I'll push it in a bit. It's been almost a week, and I suspect
that noone will take the time to review this, so I'm just going to
push it shortly without review.
On Wed, Sep 11, 2013 at 1:32 PM, Ozkan Sezer wrote:
> On 9/11/13, Peter Rosin wrote:
>> On 2013-09-10 16:10, Peter Rosin wrote:
>>> On 2013-09-10 15:56, Ozkan Sezer wrote:
OK then, I'll keep an eye on mails from this list.
(On an irrelevant note, the archive pages at
http://li
On 9/11/13, Peter Rosin wrote:
> On 2013-09-10 16:10, Peter Rosin wrote:
>> On 2013-09-10 15:56, Ozkan Sezer wrote:
>>> OK then, I'll keep an eye on mails from this list.
>>>
>>> (On an irrelevant note, the archive pages at
>>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>>> http:
On 2013-09-10 16:10, Peter Rosin wrote:
> On 2013-09-10 15:56, Ozkan Sezer wrote:
>> OK then, I'll keep an eye on mails from this list.
>>
>> (On an irrelevant note, the archive pages at
>> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
>> http://lists.gnu.org/archive/html/bug-libtool
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 15:29, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 15:00, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 12:52, Ozkan Sezer wrote:
>> That effectively cripples libtool for cross-compilers. C
On 9/10/13, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
> [...]
>>> @@ -2416,10 +2416,22 @@
>>>sys_lib_search_path_spec="$sys_lib_search_path_spec
>>> /usr/lib/w32api"])
>>>;;
>>> mingw* | cegcc*)
>>># MinGW DLLs use traditional 'lib' prefix
>>>soname_
On 9/10/13, Peter Rosin wrote:
[...]
>> @@ -2416,10 +2416,22 @@
>>sys_lib_search_path_spec="$sys_lib_search_path_spec
>> /usr/lib/w32api"])
>>;;
>> mingw* | cegcc*)
>># MinGW DLLs use traditional 'lib' prefix
>>soname_spec='$libname`echo $release | $SED -e
>> '
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 15:00, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 12:52, Ozkan Sezer wrote:
That effectively cripples libtool for cross-compilers. Can the behavior
be refined instead? Can you contact Charles Wilson about this?
On 9/10/13, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Pete
On 2013-09-10 15:56, Ozkan Sezer wrote:
> OK then, I'll keep an eye on mails from this list.
>
> (On an irrelevant note, the archive pages at
> http://lists.gnu.org/archive/html/libtool/2013-09/index.html
> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html
> doesn't list any mails f
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 11:26, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 10:55, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 09:47, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 09
On 9/10/13, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>> Can you provide the output from "libtool --config" and
>> config.log? I
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 10:55, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 09:47, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 09:08, Ozkan Sezer wrote:
>> Tell me if you need anything else.
>
> Let's foc
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 09:47, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 09:08, Ozkan Sezer wrote:
Tell me if you need anything else.
>>>
>>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>>> you.
>>>
>>> Can you provide the o
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 12:52, Ozkan Sezer wrote:
>> That effectively cripples libtool for cross-compilers. Can the behavior
>> be refined instead? Can you contact Charles Wilson about this?
>
> He should be reading this list, if he has time...
>
> Anyway, does this work?
>
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 00:34, JonY wrote:
>> On 9/10/2013 02:12, Ozkan Sezer wrote:
>>>
>>> *** Warning: linker path does not have real file for library -lole32.
>>> *** I have the capability to make that library automatically link in
>>> when
>>> *** you link to this libra
On 9/10/13, JonY <10wa...@gmail.com> wrote:
> On 9/10/2013 02:12, Ozkan Sezer wrote:
>>
>> *** Warning: linker path does not have real file for library -lole32.
>> *** I have the capability to make that library automatically link in when
>> *** you link to this library. But I can only do this if y
On 2013-09-10 15:29, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 15:00, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instea
On 2013-09-10 15:00, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 12:52, Ozkan Sezer wrote:
>>> That effectively cripples libtool for cross-compilers. Can the behavior
>>> be refined instead? Can you contact Charles Wilson about this?
>>
>> He should be reading this list,
On 2013-09-10 12:52, Ozkan Sezer wrote:
> That effectively cripples libtool for cross-compilers. Can the behavior
> be refined instead? Can you contact Charles Wilson about this?
He should be reading this list, if he has time...
Anyway, does this work?
Cheers,
Peter
diff --git a/m4/libtool.m4
On 2013-09-10 12:25, Ozkan Sezer wrote:
> On 9/10/13, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 11:26, Ozkan Sezer wrote:
On 9/10/13, Peter Rosin wrote:
> On 2013-09-10 10:55, Ozkan Sezer wrote:
>> On 9/10/13, Peter Rosin wrote:
>>> On 2013-09-10 09
On 2013-09-10 11:50, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 11:26, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/
On 2013-09-10 11:26, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 10:55, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me
On 2013-09-10 10:55, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:47, Ozkan Sezer wrote:
>>> On 9/10/13, Peter Rosin wrote:
On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that'
On 2013-09-10 09:47, Ozkan Sezer wrote:
> On 9/10/13, Peter Rosin wrote:
>> On 2013-09-10 09:08, Ozkan Sezer wrote:
>>> Tell me if you need anything else.
>>
>> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
>> you.
>>
>> Can you provide the output from "libtool --config" and
>> confi
On 2013-09-10 09:08, Ozkan Sezer wrote:
> Tell me if you need anything else.
Let's focus on the libtool 2.4.2.393-5d4a if that's ok with
you.
Can you provide the output from "libtool --config" and
config.log? I'm not set up to easily duplicate your
environment...
Cheers,
Peter
On 2013-09-10 00:34, JonY wrote:
> On 9/10/2013 02:12, Ozkan Sezer wrote:
>>
>> *** Warning: linker path does not have real file for library -lole32.
>> *** 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
>
On 9/10/2013 02:12, Ozkan Sezer wrote:
>
> *** Warning: linker path does not have real file for library -lole32.
> *** 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, wh
Hello Jason, Brian, all,
* Jason Curl wrote on Mon, Aug 20, 2007 at 11:41:03AM CEST:
> Brian Dessent wrote:
>>
[ snip nice, concise and well-written explanations ]
>>
> Brian - thanks for the concise description. Ralf - any way to may be
> add an addendum to the libtool docs for this, just for inf
Brian Dessent wrote:
.dll.a is the import library. .dll is the actual library. Both should
be produced. The import library is used when linking against the
library, but it is not needed at runtime and contains no code. It's
typically distributed in the same context as headers -- it is needed
Jason Curl wrote:
> I guess what happens if I don't say this the build will fail. I've
It should produce static libraries if it cannot produce shared ones.
> turned it on and it looks good. I'll try and search more info later, but
> while I'm at it:
> - Why is it .dll.a and not .dll?
> - How is
Brian Dessent wrote:
Jason Curl wrote:
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info
0:0:0 -o libtp.la -rpath /usr/local/lib version.lo
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
Libtool won't build shared libraries
* Brian Dessent wrote on Fri, Aug 17, 2007 at 09:49:48PM CEST:
> Jason Curl wrote:
>
> > lib -OUT:.libs/libtp.lib version.o
> > ../libtool: line 5973: lib: command not found
>
> I'm not sure why it's trying to use lib here, that seems wrong if you're
> using gcc/binutils. Possibly a configure p
Jason Curl wrote:
> /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info
> 0:0:0 -o libtp.la -rpath /usr/local/lib version.lo
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries
Libtool won't build shared libraries on Win32/PE targets witho
35 matches
Mail list logo
