similar to: problem with compiling on Cygwin64

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