* Юрий Пухальский wrote on Mon, Nov 30, 2009 at 09:15:23AM CET:
> 2009/11/28 Jack Kelly :
> > 2009/11/28 Юрий Пухальский :
> >>> My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of
> >>> libcommon.la. This goes into LDADD as with libtool convenience
> >>> libraries.
> >> I haven'
I've tried using oldstyle libraries, to no avail... It has made a
library like this (last lines of "ar t" output):
foo.o
libbar.a
2009/11/28 Jack Kelly :
> 2009/11/28 Юрий Пухальский :
>> -snip-
>>>
>>> My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of
>>> libcommon.la. This
* Юрий Пухальский wrote on Fri, Nov 27, 2009 at 11:14:04PM CET:
> It's working like a charm, the autotools system, One small thing is
> 64-bit ARFLAGS on AIX,
> but the folks out there in libtool (if i remember right) are aware of
> the problem, it seems, but i haven't investigated it yet.
Try
O
2009/11/28 Ralf Wildenhues :
> Hello Yuri, nice to read from you again,
Hello, Ralf, nice to see you too:)
It's working like a charm, the autotools system, One small thing is
64-bit ARFLAGS on AIX,
but the folks out there in libtool (if i remember right) are aware of
the problem, it seems, but i ha
2009/11/28 Jack Kelly :
> 2009/11/28 Юрий Пухальский :
>> On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly wrote:
>>> 2009/11/27 Юрий Пухальский :
Automake links binaries through libtool too, at least in my case.
>>>
-make output---
/oracle/10.2.0.4/bin/proc CODE=ANSI_C include=.
2009/11/28 Юрий Пухальский :
> -snip-
>>
>> My bad. I meant noinst_LIBRARIES, so you make a libcommon.a instead of
>> libcommon.la. This goes into LDADD as with libtool convenience
>> libraries.
> I haven't checked it, but does it support library dependencies like
> .la? This i use extensively.
Ye
Hi Jack,
* Jack Kelly wrote on Fri, Nov 27, 2009 at 10:37:55PM CET:
> 2009/11/28 Ralf Wildenhues:
> > That's why you should do it like this:
> >
> > .pc.$(OBJEXT):
> > ...
>
> I'm confused. Why is this better than writing a .pc.c rule? Doesn't it
> sacrifice proper dependency tracking on t
Hi Ralf,
2009/11/28 Ralf Wildenhues :
> That's why you should do it like this:
>
> .pc.$(OBJEXT):
> ...
I'm confused. Why is this better than writing a .pc.c rule? Doesn't it
sacrifice proper dependency tracking on the generated .c file?
-- Jack
Hello Yuri, nice to read from you again,
* Юрий Пухальский wrote on Fri, Nov 27, 2009 at 10:38:15AM CET:
> Automake links binaries through libtool too, at least in my case.
Yes, but it doesn't compile the objects for non-libraries using libtool,
just like Jack explained.
> And yes, it works when
2009/11/28 Юрий Пухальский :
> On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly wrote:
>> 2009/11/27 Юрий Пухальский :
>>> Automake links binaries through libtool too, at least in my case.
>>
>>> -make output---
>>> /oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include
>>> include=/oracle
On Fri, Nov 27, 2009 at 4:07 PM, Jack Kelly wrote:
> 2009/11/27 Юрий Пухальский :
>> Automake links binaries through libtool too, at least in my case.
>
>> -make output---
>> /oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include
>> include=/oracle/10.2.0.4/lib include=/usr/include ir
Automake links binaries through libtool too, at least in my case.
-make output---
/oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include
include=/oracle/10.2.0.4/lib include=/usr/include ireclen=4800
oreclen=4800 select_error=no release_cursor=no hold_cursor=yes
lines=yes ltype=none c
2009/11/27 Юрий Пухальский :
> Automake links binaries through libtool too, at least in my case.
> -make output---
> /oracle/10.2.0.4/bin/proc CODE=ANSI_C include=../../include
> include=/oracle/10.2.0.4/lib include=/usr/include ireclen=4800
> oreclen=4800 select_error=no release_cursor=no
2009/11/25 Юрий Пухальский :
> Good day!
>
> As of automake 1.11 the following problem exists:
> I have a nonstandard suffix .pc (ProC source), which i compile into .lo with
> SUFFIXES = .pc
> .pc.lo:
> $(PCC) $(PCCFLAGS) iname=$(srcdir)/$*.pc oname=$(builddir)/$*.c
> $(LIBTOOL) --tag
14 matches
Mail list logo
