Displaying 20 results from an estimated 800 matches similar to: "problem with compiling on Cygwin64"
2015 Oct 23
2
problem with compiling on Cygwin64
Thank you for responding to my problem
I have no problem building in Debian 8 , the problem is with Cygwin64
I see that the two lines from
Cygwin64 >>
gcc -g -O2 -Wall -Wsign-compare usbhid-ups.c -o usbhid-ups
In file included from usbhid-ups.c:32:0:
And
Debian>>>
make[1]: Entering directory '/home/walter/nut/drivers'
depbase=`echo usbhid-ups.o | sed
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 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 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"
2005 Oct 03
1
CyberPower SL-series
This code, added to drivers/genericups.h, supports the CyberPower SL
series UPSes. I've tested with my 725SL - the online/on battery
transition, and low battery status, and finally the shutdown signal all
work as expected.
*** genericups.h.orig Sun Nov 2 16:54:24 2003
--- genericups.h Mon Oct 3 13:49:00 2005
***************
*** 220,225 ****
--- 220,234 ----
TIOCM_ST
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>
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 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>
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
2009 Dec 07
2
xapain install
Hi,
I am trying to isntall Xapain. I run $./cofigure optionand then I rune make, but it echos following message in infinite loop. Is there anything wrong? How to correct?
---------------------------------
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I./common -I./include -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long
2016 Apr 08
2
Commit 68f4ca7 issues
There are few reasons why I stick to older OSes.
In case of FreeBSD its my customized Imunes platform
for network simulations...
Anyway, back to root problem:
gcc -std=gnu99 -DHAVE_CONFIG_H -DCONFDIR=\"/etc\" -DLOCALSTATEDIR=\"/var\"
-DFORTIFY_SOURCE=2 -g -O2 -MT tincd.o -MD -MP -MF $depbase.Tpo -c -o tincd.o
tincd.c &&\
mv -f $depbase.Tpo $depbase.Po
2015 Jul 06
2
[Nut-upsuser] Nut-2.7.3 & gcc-3.3.6
Hi Charles,
Thanks for the prompt reply!
Errors occur when execute make:
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../include -MT nutclient.lo -MD -MP -MF $depbase.Tpo -c -o
nutclient.lo nutclient.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo
-MD -MP -MF .deps/nutclient.Tpo -c
2014 Mar 10
2
Building Opus (git master) ARM assembly for iOS
I?m trying to build Opus (git master) for iOS, and it doesn?t build unless I disable the ARM assembly.
It looks like the problem is that Apple?s assembler doesn?t support all the assembler directives that the GNU assembler does. I suspect this is a combination of the fact that Apple platforms are Mach-O rather than Elf, and just the fact that Apple?s assembler is extremely divergent from the
2015 Jul 08
0
[Nut-upsuser] Nut-2.7.3 & gcc-3.3.6
On Jul 6, 2015, at 10:32 AM, Sergey Talchuk <tals1975 at gmail.com> wrote:
> /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF $depbase.Tpo -c -o nutclient.lo nutclient.cpp &&\
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../include -MT nutclient.lo -MD -MP -MF
2016 Apr 08
0
Commit 68f4ca7 issues
On Fri, Apr 08, 2016 at 02:55:10PM +0200, borg at uu3.net wrote:
> There are few reasons why I stick to older OSes.
> In case of FreeBSD its my customized Imunes platform
> for network simulations...
Hm, I just tried FreeBSD 4.11 in a VM and it seems it doesn't support
C99 at all. So I guess you already had to install a newer GCC and what
not to get things running :)
> Anyway,
2015 Jul 04
2
Trouble installing xapian on windows
Hello, i am trying to install xapian on windows. As the xapian download page says, there are two options here:
1) mingw
2) a separate set of makefiles for MSVC.
If i understand correctly, MSVC is supported only by xapian 1.2.8 and older, so i decided to try mingw. The configure script worked perfectly, but "make" finished with a error (see the output below). So far i have two
2018 Oct 02
2
Can't build xapian-bindings in a virtual env
Hi,
I'm on a Ubuntu 18.04 server, trying to use django-haystack with xapian
in a python3.6 virtualenv.
The virtualenv is set up not to use system packages, meaning that I
can't just install python3-xapian-haystack with apt, and instead have to
manually build xapian-core and xapian-bindings within the virtualenv.
This works with xapian-core and the --prefix argument to configure. When
I
2015 Jul 08
1
[Nut-upsuser] Nut-2.7.3 & gcc-3.3.6
Hi Charles,
Yes, it looks like my g++ does contain STL library which might be just my
specific case...
However, as a temporary solution I disabled nutclient in Makefile (please
find the file attached). And nut-2.7.3 can be compiled now.
Thanks,
Sergey
On Wed, Jul 8, 2015 at 4:13 AM, Charles Lepple <clepple at gmail.com> wrote:
> On Jul 6, 2015, at 10:32 AM, Sergey Talchuk