Displaying 20 results from an estimated 5000 matches similar to: "problem with compiling on Cygwin64"
2015 Oct 23
1
problem with compiling on Cygwin64
I am trying to compile the latest nut version on Cygwin64 and have run into
his issue
Any Ideas??
gcc -DHAVE_CONFIG_H -I. -I../include -I../include -I/usr/include/neon
-g -O2 -Wall -Wsign-compare -MT genericups.o -MD -MP -MF $depbase.Tpo -c -o
genericups.o genericups.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from genericups.c:24:0:
genericups.h:147:4: error:
2015 Oct 24
2
problem with compiling on Cygwin64
libusb do you have installed >>> 1.2.6.0-2
./configure --with-drivers=usbhid-ups
Configuration summary:
======================
build serial drivers: yes
build USB drivers: yes
build SNMP drivers: no
build neon based XML driver: yes
enable Avahi support: no
build Powerman PDU client driver: no
build IPMI driver: no
build Mac OS X meta-driver: no
build i2c based drivers: no
enable SSL
2015 Nov 02
1
problem with compiling on Cygwin64
Success !! at least in the compile and build of the Cygwin *.exe's
git clone git://github.com/networkupstools/nut.git
./autogen.sh
cd nut
./autogen.sh
./configure --with-all=auto --with-doc=auto
make install
problem was in :
/* genericups.c - support for generic contact-closure UPS models
Copyright (C) 1999 Russell Kroll <rkroll at exploits.org>
This program is free
2015 Nov 01
0
problem with compiling on Cygwin64
On Oct 24, 2015, at 12:11 PM, Walter Literowich <wliterow at gmail.com> wrote:
>
> Making all in drivers
> make[1]: Entering directory '/cygdrive/c/nut/drivers'
> gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups
> In file included from usbhid-ups.c:32:0:
> main.h:4:20: fatal error: common.h: No such file or directory
> #include
2015 Oct 24
0
problem with compiling on Cygwin64
On Oct 23, 2015, at 4:18 PM, Walter Literowich <wliterow at gmail.com> wrote:
>
> Making all in drivers
> make[1]: Entering directory '/cygdrive/c/nut/drivers'
> gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups
> In file included from usbhid-ups.c:32:0:
> main.h:4:20: fatal error: common.h: No such file or directory
> #include "common.h"
2012 Jul 31
0
No subject
This is the config line used:-
PKG_CONFIG_PATH=3D"$HOME/builds/lib/pkgconfig" LDFLAGS=3D"-L$HOME/builds/li=
b" CFLAGS=3D"-I$HOME/builds/include" ./configure --prefix=3D$HOME/builds --=
host=3Di686-w64-mingw32 --disable-stack-protector
@xubuntu:~/builds/bin$ wine ./opusenc -V
opusenc opus-tools 0.1.5 (using libopus 1.0.1)
Copyright (C) 2008-2012 Xiph.Org Foundation
2015 Oct 31
0
compiling on Cygwin64
Has anyone successfully compiled the latest version of NUT on Cygwin64
Having problems with configure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20151030/76da029d/attachment.html>
2013 Sep 24
5
Problem compiling opus-tools-0.1.7
Hi
I'm having a problem compiling opus-tools-0.1.7.
Version opus-tools-0.1.6 seems to compile OK.
I've tried with opus-1.0.3 and opus-1.1-beta.
The errors are like this:-
"undefined reference to `sqrtf'" etc.
This OS is Peppermint Three, similar to Ubuntu 12.04.
It uses:-
gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Google says it's maybe something to do
2008 Feb 24
1
nut-subversion Tripp Lite 750AVR
Hi, i new on this list i don't know if this goes on development list or this list,? i have a ups Tripp Lite 750AVR(lusb info in the attach)? , i retrieve the current development tree from the subvervsion repo, and trying to compile NUT on Fedora8 to test the usb driver.
the configure is ok:
Configuration summary:
enable SSL development code: yes
enable IPv6 support: yes
build
2015 Mar 09
2
Install problems (group permissions) with nut 2.7.2
Ok, I tried this from scratch on a fresh 2.7.2 directory. I followed the web instructions, specifically:
+ I generated the new subdriver for my UPS (rtd-hid.*) based on PATH info.
+ I put them in the drivers subdir
+ I added the include line (#include rtd-hid.h) in usbhid-ups.c (specifically in the #ifndef SHUT_MODE section)
+ I added &rtd_subdriver, to the subdriver_list in usbhid-ups.c
2011 Jan 21
1
Building nut 2.6.0 on OpenBSD 4.8 - compile issue
Trying to build nut 2.6.0 on OpenBSD 4.8, I get a compiler error.
Here's my configure:
./configure --with-user=_ups --with-group=_ups \
--sysconfdir=/etc/ups --with-usb=no
... and the result:
-e Configuration summary:
======================
build serial drivers: yes
build USB drivers: no
build SNMP drivers: no
build neon based XML driver: no
build Powerman PDU client driver:
2015 Jul 23
1
[LLVMdev] DebugInfo/PDB/pdbdump-symbol-format.test fails with VS 2015
Ok just tried on Win 7 and the same problem occurs. I am building with :
cmake -G "Ninja" -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_CRT_RELEASE=MT
-DLLVM_ENABLE_TIMESTAMPS=ON -DLLVM_ENABLE_ASSERTIONS=ON
-DLLVM_INSTALL_TOOLCHAIN_ONLY=ON -DLLVM_TARGETS_TO_BUILD="ARM;X86"
-DPYTHON_EXECUTABLE=$python_exe -DLLVM_BUILD_TESTS=ON
-DLLVM_LIT_TOOLS_DIR=C:/cygwin64/bin
fwiw compiler-rt is
2015 Jul 21
0
[LLVMdev] DebugInfo/PDB/pdbdump-symbol-format.test fails with VS 2015
FWIW, this test is passing for me on Windows 7 with Visual Studio 2015
(debug build).
59> Running all regression tests
59> -- Testing: 23734 tests, 32 threads --
59>
59> Testing Time: 634.19s
59> Expected Passes : 22821
59> Expected Failures : 160
59> Unsupported Tests : 753
59> lit.py: lit.cfg:195: note: using clang:
2015 Jul 21
4
[LLVMdev] DebugInfo/PDB/pdbdump-symbol-format.test fails with VS 2015
Hi,
This might be interesting since it seems to be the only LLVM test
failing with VS 2015:
FAIL: LLVM :: DebugInfo/PDB/pdbdump-symbol-format.test (7377 of 14212)
******************** TEST 'LLVM ::
DebugInfo/PDB/pdbdump-symbol-format.test' FAILED ********************
Script:
--
llvm-pdbdump -symbols
C:\cygwin64\home\ismail\src\llvm\test\DebugInfo\PDB/Inputs/symbolformat.pdb
|
2007 Mar 06
3
make errors on solaris express dev 02/07
make fails at drivers:
make[1]: Entering directory `/export/home/zoly/Documents/trunk/drivers'
/bin/sh ../libtool --tag=CC --mode=link gcc -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/sfw/include -g -Dsolaris2 -I. -I/usr/sfw/include -O -Wall -Wsign-compare -o al175 al175.o ../common/libcommon.a ../common/upsconf.o
2015 Nov 01
0
problem with compiling on Cygwin64
....just a hunch...
http://www.cs.nyu.edu/rgrimm/teaching/fa05-oop/windows-make.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20151102/383f1739/attachment.html>
2005 Dec 28
1
Problems with klibc 1.1.8
Hi,
trying to build klibc 1.1.8 on x86 fails on my machine as follows:
KLIBCCC dash/trap.o
KLIBCCC dash/output.o
dash/trap.c: In function 'trapcmd':
dash/trap.c:94: warning: unused parameter 'argc'
dash/trap.c:94: warning: unused parameter 'argv'
dash/trap.c: In function 'decode_signal':
dash/trap.c:398: error: 'SIGRTMIN' undeclared (first use in this
2012 Jun 13
2
[LLVMdev] llvm-mc problem after a pass
Hi,
I'm having some problem with llvm-mc on a program after applying a pass:
../../../build/Release+Asserts/bin/clang -emit-llvm -c -I./testprof/ -I./src/headers/ -I../libtommath-0.42.0/ -Wall -Wsign-compare -W -Wshadow -Wno-unused-parameter -DLTC_SOURCE -O0 -DLTC_NO_ASM -DUSE_LTM -DLTM_DESC -o src/pk/asn1/der/sequence/der_encode_sequence_ex.bc
2010 Jul 21
1
-mtune=generic failure
redhat enterprise 4 (still widely in use in coorp env.)
$ g++ --version
g++ (GCC) 3.4.6 20060404 (Red Hat 3.4.6-11)
make[2]: Entering directory `/usr/src/xapian/xapian-core-1.2.2/.build'
depbase=`echo api/decvalwtsource.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I.. -I../common -I../include -I./include
2016 Feb 09
2
Compilation failure using mingw-w64 and gcc-5.3.0
Thank you for the feedback.
This is cross-compiling for mingw-w64-x86_64 using gcc-5.3.0 and
mingw-w64-4.0.4 on GNU/Linux.
Upon attempting to compile now, a large number of errors occur in
flac/decode.c which I have placed at the end of this email. They are eased
by adding this to decode.c:
#if _WIN32
#include <windows.h>
#include <shlobj.h>
#endif
...among the headers.
Then, this