I'll try it on 2.7.
>IIRC SF CF only has Solaris 9 and the problems in question happens on
Solaris
2.6 and 7 with the configure line I posted.
>As for make vs. gmake, that's most definitely not the point here if
configure
leaves us with an empty top-level Makefile, isn't it?
This communication
Wes Hardaker wrote:
>> "BS" == Bruce Shaw <[EMAIL PROTECTED]> writes:
>
>>> Did you figure out why? Is this another sed problem or something else?
>
> WH> No idea (and no time today). Can anyone else reproduce this on Solaris?
>
> BS> There is no gmake on Solaris. What's wrong with good ol
> "BS" == Bruce Shaw <[EMAIL PROTECTED]> writes:
>> Did you figure out why? Is this another sed problem or something else?
WH> No idea (and no time today). Can anyone else reproduce this on Solaris?
BS> There is no gmake on Solaris. What's wrong with good old fashioned make?
I just built
Wes Hardaker wrote:
>> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
>
> TA> Not that much "later", unfortunately:
>
> TA> solaris27# ~/src/net-snmp-5.4cvs/configure --with-defaults
> TA> --enable-mfd-rewrites --with-mib-modules="if-mib udp-mib tcp-mib"
>>> myconfig.log 2>&1 && gmake
> TA
Wes Hardaker wrote:
>> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
>
> TA> Not that much "later", unfortunately:
>
> TA> solaris27# ~/src/net-snmp-5.4cvs/configure --with-defaults
> TA> --enable-mfd-rewrites --with-mib-modules="if-mib udp-mib tcp-mib"
>>> myconfig.log 2>&1 && gmake
> TA
> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
TA> Not that much "later", unfortunately:
TA> solaris27# ~/src/net-snmp-5.4cvs/configure --with-defaults
TA> --enable-mfd-rewrites --with-mib-modules="if-mib udp-mib tcp-mib"
>> myconfig.log 2>&1 && gmake
TA> gmake: *** No targets. Stop.
TA
Dave Shield wrote:
> Actually, Wes has now addressed the immediate problem using a
> different mechanism altogether. The same issue may re-appear later
> with some of the other module substitutions, but the header file
> handling was definitely the most problematic.
> Now sorted.
Not that much "
> "TA" == Thomas Anders <[EMAIL PROTECTED]> writes:
TA> Please note that the 5.[23].x branches still suffer the same issue in
TA> general. If the fix is considered clean and safe enough, can it please
TA> be applied to the branches, too?
It should be safe, yes.
--
Wes Hardaker
Sparta, Inc.
Dave Shield wrote:
> Actually, Wes has now addressed the immediate problem using a
> different mechanism altogether. The same issue may re-appear later
> with some of the other module substitutions, but the header file
> handling was definitely the most problematic.
> Now sorted.
Please note tha
On 18/10/06, Albert Chin <[EMAIL PROTECTED]> wrote:
> The only other option is to split the string fed to sed into multiple lines.
Actually, Wes has now addressed the immediate problem using a
different mechanism altogether. The same issue may re-appear later
with some of the other module substi
On Wed, Oct 18, 2006 at 09:04:43AM +0100, Dave Shield wrote:
> Finding the "best" sed is obviously a good thing, but what if this is
> not sufficient?
> The project needs to be able to run on a system where *none* of the
> installed 'sed's can handle the list of module headers.
The only other opti
On 18/10/06, Albert Chin <[EMAIL PROTECTED]> wrote:
> What version of autoconf are you using? I think 2.60 fixes this by
> searching the system for the "best" sed.
2.59
Updating autoconf is certainly one option. But we don't like making
such changes at this stage in the release cycle. Dropping t
On Tue, Oct 10, 2006 at 05:05:53PM +0100, Dave Shield wrote:
> Thomas & I have been discussing the problems with an over-long 'sed'
> line breaking configure on the latest 5.4 code. Further
> investigation shows that there are three substitutions which are
> failing, resulting from the entries:
>
Bruce Shaw wrote:
> One problem may be with sed itself.
Huh? The *whole* issue here is how to properly deal with sed limitations at
configure time.
> I routinely patch to Sun's recommendation, but somehow the sed patch was
> missed on at least on of my development boxes.
>
> I had to add patch 1
One problem may be with sed itself.
>> As a short-term fix, it would be possible to temporarily drop the
>> above three lines from configure.in, and comment out the corresponding
>> lines in agent/Makefile.in
>Unfortunately configure seems to use hard-coded calls to 'sed' in
>AC_OUTPUT, so I don'
On Tue, 10 Oct 2006 17:05:53 +0100 Dave wrote:
DS> Thomas & I have been discussing the problems with an over-long 'sed'
DS> line breaking configure on the latest 5.4 code. Further
DS> investigation shows that there are three substitutions which are
DS> failing, resulting from the entries:
DS>
DS
Dave Shield wrote:
> As a short-term fix, it would be possible to temporarily drop the
> above three lines from configure.in, and comment out the corresponding
> lines in agent/Makefile.in
Unfortunately configure seems to use hard-coded calls to 'sed' in
AC_OUTPUT, so I don't see a way to have con
Thomas & I have been discussing the problems with an over-long 'sed'
line breaking configure on the latest 5.4 code. Further
investigation shows that there are three substitutions which are
failing, resulting from the entries:
AC_SUBST( module_list_h)
AC_SUBST( mib_module_list_h)
AC_
18 matches
Mail list logo
