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 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 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 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 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 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 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 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 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 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
I have used thic command
libtool --mode=compile gcc -g -o -c foo.c
The .o file is creating in the current directory. .libs in not creating.
Actual output should be like this after the command:
$libtool --mode=compile gcc -g -O -c foo.c
mkdir .libs
gcc -g -O -c foo.c -fPIC -DPIC -o .l
Hello,
Glad seeing this being addressed :-)
On Tue, Sep 10, 2013 at 12:41 AM, Brooks Moses wrote:
> Hello, Marco,
>
> Thanks for pinging this -- I'm trying to work through some of the libtool
> patch backlog, and I'll have a look at this in the next few days.
>
> I note that David Turner also p
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 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 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, 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, 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 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, 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 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, 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:
> 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 Tue, Sep 10, 2013 at 1:05 AM, David Turner wrote:
> For the record, I've kept the $release to keep the structure similar to the
> glibc one. I admit I don't really know what that corresponds to, but I could
> successfully build working shared libraries for a few projects with my
> patch. Good e
25 matches
Mail list logo
