On Tue, Apr 2, 2024 at 6:05 PM Karl Berry wrote:
>
> I'm also wondering whether the GNU system should recommend using zstd
> instead of or in addition to xz for compression purposes.
>
> I'm not sure GNU explicitly recommends anything. Although the tarball
> examples in standards.texi and
I'm having this problem on 32-bit ARM:
https://stackoverflow.com/q/33474070/608639
Our bin_* recipe looks like this:
bin_PROGRAMS = cryptest
cryptest_CXXFLAGS = $(AM_CXXFLAGS)
cryptest_SOURCES = \
test.cpp bench1.cpp bench2.cpp \
validat1.cpp validat2.cpp validat3.cpp
cryptest_LDADD = $
On Thu, Jan 4, 2018 at 7:45 AM, Mathieu Lirzin wrote:
> Hello,
>
> Jeffrey Walton writes:
>
>> On Wed, Jan 3, 2018 at 10:00 AM, Mathieu Lirzin wrote:
>>>
>>> Jeffrey Walton writes:
>>>
>>>> I'm trying to update Autoconf and Au
On Wed, Jan 3, 2018 at 10:00 AM, Mathieu Lirzin wrote:
>
> Jeffrey Walton writes:
>
>> I'm trying to update Autoconf and Automake on an old CentOS system.
>> The build is failing with:
>>
>> MAKEINFO doc/automake.info
>> /home/scripts/automake-1.15.1
I'm trying to update Autoconf and Automake on an old CentOS system.
The build is failing with:
MAKEINFO doc/automake.info
/home/scripts/automake-1.15.1/lib/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
You should only need it if you modifie
On Tue, Nov 14, 2017 at 4:00 PM, Bob Friesenhahn
wrote:
>>> Or maybe something else?
>>
>> It looks like the extra files provided by libtool are the problem. It
>> looks like the libtool folks need to add _XOPEN_SOURCE=600 to their
>> preprocessor definitions. I'm guessing they only test with a C
On Tue, Nov 7, 2017 at 6:10 PM, Jeffrey Walton wrote:
> I'm testing on MinGW (). I'm surprised how easily the library built
> for MinGW under Autotools. Hat's off for the good job.
>
> I'm down to one error from what appears to be an Automake source file
> (see
On Wed, Nov 8, 2017 at 3:53 PM, Jeffrey Walton wrote:
> On Tue, Nov 7, 2017 at 12:33 PM, Jeffrey Walton wrote:
>> I'm trying to run 'make check' on Solaris. It results in:
>>
>> $ ./cryptestcwd v
>> ld.so.1: cryptestcwd: fatal:
>> /export/home/cryp
On Tue, Nov 7, 2017 at 12:33 PM, Jeffrey Walton wrote:
> I'm trying to run 'make check' on Solaris. It results in:
>
> $ ./cryptestcwd v
> ld.so.1: cryptestcwd: fatal:
> /export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
> (CA_SUNW_HW_1) uns
On Tue, Nov 7, 2017 at 12:33 PM, Jeffrey Walton wrote:
> I'm trying to run 'make check' on Solaris. It results in:
>
> $ ./cryptestcwd v
> ld.so.1: cryptestcwd: fatal:
> /export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
> (CA_SUNW_HW_1) uns
I'm testing on MinGW (). I'm surprised how easily the library built
for MinGW under Autotools. Hat's off for the good job.
I'm down to one error from what appears to be an Automake source file
(see below). I'm not a MinGW expert and searching is not returning
useful results. I test the platform to
I'm trying to run 'make check' on Solaris. It results in:
$ ./cryptestcwd v
ld.so.1: cryptestcwd: fatal:
/export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
(CA_SUNW_HW_1) unsupported: 0x480 [ AES SSE4.1 ]
Killed
I have a Mapfile to set the capabilities for the binaries, and it
On Sat, Nov 4, 2017 at 5:00 PM, Nick Bowler wrote:
> On 11/4/17, Jeffrey Walton wrote:
>> ...
>> One of our driving principles is "things just work". We don't want
>> library users inconvenienced or installing extra software. They should
>> be able to
On Sat, Nov 4, 2017 at 3:56 PM, Nick Bowler wrote:
> Hello,
>
>> EXTRA_libcryptopp_la_DEPENDENCIES listing the objects worked for Linux
>> and OS X, but not Solaris. For Solaris I needed to drop the leading
>> `EXTRA`, and use just `libcryptopp_la_DEPENDENCIES`.
>
> Is that just because you happen
On Fri, Nov 3, 2017 at 3:07 PM, Jeffrey Walton wrote:
> On Fri, Nov 3, 2017 at 1:51 PM, Nick Bowler wrote:
>> On 11/3/17, Jeffrey Walton wrote:
>>> On Thu, Nov 2, 2017 at 6:04 PM, Jeffrey Walton wrote:
>>>> ...
>>> The new issue is, the compile
Hi Everyone,
I'm having trouble selecting the preferred AR in Makefiles on Apple
systems. The default value (even when calling AM_PROG_AR) is:
$ egrep 'AR =|ARFLAGS =' Makefile
AMTAR = $${TAR-tar}
AR = ar
ac_ct_AR = ar
On Apple systems we need Apple's libtool at /usr/bin/libtool (not
Hi Everyone,
One last question for the moment...
We build our test program 'cryptest' with hard-coded path using
$prefix.The test vectors can be located at $prefix/share/..., and
everything works as expected after 'make install'.
We also build a second test program intended to be run in-situ, an
On Fri, Nov 3, 2017 at 1:51 PM, Nick Bowler wrote:
> On 11/3/17, Jeffrey Walton wrote:
>> On Thu, Nov 2, 2017 at 6:04 PM, Jeffrey Walton wrote:
>>> ...
>> The new issue is, the compile stops after about 4 files are compiled.
>> Here's the pastebin of `make
On Fri, Nov 3, 2017 at 1:51 PM, Nick Bowler wrote:
> On 11/3/17, Jeffrey Walton wrote:
>> On Thu, Nov 2, 2017 at 6:04 PM, Jeffrey Walton wrote:
>>> I'm working on adding Autotools to a C++ library and test program. My
>>> Automake.am has:
>>>
>>>
On Thu, Nov 2, 2017 at 6:04 PM, Jeffrey Walton wrote:
> I'm working on adding Autotools to a C++ library and test program. My
> Automake.am has:
>
>
> ...
I believe I applied Nick and Mathieu correctly. The project is
available at https://github.com/noloader/cryptopp-autotoo
Hi Everyone,
This is related to Nick and Mathieu's comments about per-object flags
and use of CXXFLAGS.
When I change the pattern to:
CPU_FLAG = -msse2
libcpu_a_SOURCES = cpu.cpp
libcpu_a_CXXFLAGS += $(CPU_FLAG)
I encounter:
Makefile.am:64: error: libcpu_a_CXXFLAGS must be set with '='
On Thu, Nov 2, 2017 at 8:37 PM, Nick Bowler wrote:
> Hi Jeffrey,
>
> On 11/2/17, Jeffrey Walton wrote:
>> I'm working on adding Autotools to a C++ library and test program. My
>> Automake.am has:
>>
>> lib_LTLIBRARIES = \
>>libcryptopp.la
>>
On Fri, Nov 3, 2017 at 5:54 AM, Mathieu Lirzin wrote:
> Hello,
>
> Nick Bowler writes:
>>
>> On 11/2/17, Jeffrey Walton wrote:
>>>
>>> CPU_FLAG = -msse2 -msse3 -mssse3
>>> libcpu_a_SOURCES = cpu.cpp
>>> libcpu_a_CXXFLAGS = $(CXX
I'm working on adding Autotools to a C++ library and test program. My
Automake.am has:
lib_LTLIBRARIES = \
libcryptopp.la
libcryptopp_la_SOURCES = \
cryptolib.cpp \
cpu.cpp \
integer.cpp \
...
cpu.cpp needs additional flags to enable ISAs on IA-32, Aarch64 and
Power7/Power8. A
On Mon, Dec 17, 2012 at 3:07 AM, Peter Rosin wrote:
> Hi Rheinländer!
>
> On 2012-12-17 01:41, Rheinländer wrote:
>> Hi,
>>
>> here is a suggestion how to make MSVC (cl.exe) recognize the standard
>> extension for assembly code in C projects: Just add the compiler
>> switch /Tc before the file inq
On Sun, Dec 9, 2012 at 7:14 PM, Diego Elio Pettenò
wrote:
> On 09/12/2012 23:06, Jeffrey Walton wrote:
>> Seems reasonable (otherwise a stack trace is useless). Also, it does
>> not affect performance. Confer: "How does the gcc -g option affect
>> performance?" http
On Sun, Dec 9, 2012 at 3:44 PM, Diego Elio Pettenò
wrote:
> On 09/12/2012 17:32, NightStrike wrote:
>> It's not more fully documented elsewhere, though. AM_CPPFLAGS right
>> about it is, however, fully documented right in this section. This
>> should be fixed, since nowhere does the manual say t
indir=''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
default_cfgpath=''
default_incpath=''
default_libexec=''
default_libpath=''
default_varpath=''
docdir='${datarootdir}/doc/${PACKAGE}'
dvidir='
Hi All,
When I try and run configure with -fPIC -pic (as opposed to -fPIE
-pie), I receive "C compiler cannot create executables".
./configure CFLAGS="-Wall -Wextra -Wconversion -fPIC -pic
-Wno-unused-parameter -Wformat=2 -Wformat-security
-fstack-protector-all -Wstrict-overflow -Wl,-z,noexecstac
On Sat, Aug 4, 2012 at 1:10 PM, Marcelo Zimbres wrote:
> Hi,
>
> I am having some trouble to debug programs built from autotools. I am
> following the steps:
>
> $ ./configure CXXFLAGS="-g -O0"
> $ make
> $ libtool --mode=execute gdb --arg ./swat_find arg_list
>
> When I run the last line, I get t
30 matches
Mail list logo
