On Fri, Aug 23, 2013 at 10:39:42AM +0200, Peter Rosin wrote:
> On 2013-08-22 17:48, Alan Modra wrote:
> > On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
> >>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
> >>> explicitly 64-bit? That seems like utter gar
On 2013-08-22 17:48, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
>>> explicitly 64-bit? That seems like utter garbage to me. What am I
>>> missing this time?
>
> As far as I underst
On Fri, Aug 23, 2013 at 11:10:09AM +0700, Gary V. Vaughan wrote:
> Thanks for the explanation, I finally do get it. Phew :)
Oh good, because I'm not sure I really understood it despite writing
an explanation. :)
> I believe I already fixed it with the most recent amendment committed
> under you
Hi Alan,
Thanks for the fast feedback.
On Aug 22, 2013, at 10:48 PM, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
>>> explicitly 64-bit? That seems like utter garbage to me. What a
On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
> > How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
> > explicitly 64-bit? That seems like utter garbage to me. What am I
> > missing this time?
As far as I understand, this piece of libtool is supplying ld op
Hi Peter,
On Aug 22, 2013, at 8:58 PM, Peter Rosin wrote:
> On 2013-08-22 10:20, Gary V. Vaughan wrote:
>> On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
>>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
> Can we please get this simple patch pushed?
Done.
>>>
>>> To me, it appears
On 2013-08-22 10:20, Gary V. Vaughan wrote:
> Hi Peter,
>
> On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
>
>> On 2013-08-22 09:40, Gary V. Vaughan wrote:
Can we please get this simple patch pushed?
>>>
>>> Done.
>>
>> To me, it appears as if what you actually pushed was not what was post
Hi Peter,
On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote:
> On 2013-08-22 09:40, Gary V. Vaughan wrote:
>>> Can we please get this simple patch pushed?
>>
>> Done.
>
> To me, it appears as if what you actually pushed was not what was posted?
I am an idiot. Thanks for the heads up, fixed in t
On 2013-08-22 09:40, Gary V. Vaughan wrote:
>> Can we please get this simple patch pushed?
>
> Done.
To me, it appears as if what you actually pushed was not what was posted?
Cheers,
Peter
___
https://lists.gnu.org/mailman/listinfo/libtool
Hi Brooks, Alan,
On Aug 22, 2013, at 12:59 AM, Brooks Moses wrote:
> Ping?
>
> (And adding libtool@, in hopes of getting a little more attention, as pings
> on libtool-patches@ seem to be going nowhere.)
>
> On 06/05/2013 07:01 PM, Alan Modra wrote:
>> This adds s
Ping?
(And adding libtool@, in hopes of getting a little more attention, as
pings on libtool-patches@ seem to be going nowhere.)
On 06/05/2013 07:01 PM, Alan Modra wrote:
This adds support for little-endian powerpc linux, and tidies the
existing host match for powerpc. config.sub won
Yes, I know I'm annoying...
configure already checks for needed gcc options:
checking for gcc option to produce PIC...
So why don't go with it and use the option which is issued here from
configure? What are all the tests good for if finally libtool overrides
it with its own flags?
Gerrit
--
Hi Charles,
yet another contra:
> You're missing the point. *libtool* doesn't know that -DPIC means
> nothing for your code. On some platforms, you really have to compile
> DIFFERENT CODE, not just compile the same code in a different way
> (-fpic), when you want to make a pic object.
Don't
Charles Wilson wrote:
That's a gmp bug, not a libtool bug.
And I don't think so. IMO all assembler code cannot be compiled on
Cygwin when you use -DPIC to compile it. If libtool is used as it is
now, the compilation will fail, so libntool should care about this and
don't use this flag in case pla
Hi Charles,
I just don't think it is good idea to use flags for s.th. else just
because they are there anywhere. If there is need for anther special
flag then introduce it, exactly for this reason and this platform and
for nothing else. DLL_EXPORT is the best example, if there is really a
need fo
Gerrit P. Haase wrote:
I think it is a bad thing to add -D flags unconditionally and for sure
it is a bad thing if it is a noop.
You're missing the point. *libtool* doesn't know that -DPIC means
nothing for your code. On some platforms, you really have to compile
DIFFERENT CODE, not just compil
On Thu, Oct 14, 2004 at 03:17:57AM -0400, Charles Wilson wrote:
> I'm not convinced that it is a BAD thing to emit a -Dcode indicating
> when a source file is being compiled for a shared object, even when just
> considering cygwin alone. I can see cases where one might want to
> implement somet
Hi Charles,
> Libtool gives -DPIC -DDLL_EXPORT to indicate a cygwin or mingw DLL. We
> undefine PIC since we don't need to be position independent in this
> case and definitely don't want the ELF style _GLOBAL_OFFSET_TABLE_ etc.
> ifdef(`DLL_EXPORT',`undefine(`PIC')')
> Now, on *mingw*, we do i
Gerrit P. Haase wrote:
Noah Misch wrote:
There was a thread about this general topic awhile ago. That GMP
actively uses
-DPIC to select the correct assembly came up:
http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html
I saw that -DPIC was used on Cygwin to compile assembly and it co
Noah Misch wrote:
On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote:
Gerrit wrote:
PING!
Hello,
With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
generated assembly is broken. I saw this problem with a
reautoconfiscated version of GMP. This may be unusual, but
On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote:
> Gerrit wrote:
>
> PING!
>
> > Hello,
>
> > With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
> > generated assembly is broken. I saw this problem with a
> > reautoc
Gerrit wrote:
PING!
> Hello,
> With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
> generated assembly is broken. I saw this problem with a
> reautoconfiscated version of GMP. This may be unusual, but there was
> libtool used to invoke gas.
> While -DPIC i
Is this mailinglist still alive?
Greetings
Franz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Hi,
I've sent in the patch below last week and didn't get a reply ;(.
I'd like to know if my libtool patch is O.K., or is being rejected for some
reason, and how I can fix it in that case.
cheers,
dalibor topic
--- Dalibor Topic <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> the libtool m4 macros ch
Charles,
It looks to me like you'll need to have a copyright assignment
for these changes, refer to the Libtool web page for info
on how to file them. I'll try to get to your changes when I can.
Thanks,
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technica
Can someone with checkin priveleges please review the patches I posted
to this list last week (I tried to send them to libtool-patches five
days before THAT but couldn't as I am not subscribed).
I mentioned in the first email (of three) that you also need a fixed
automake. However, that is ne
26 matches
Mail list logo