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 t
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 unusu
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 is a noop for usual
11 matches
Mail list logo
