[Fink-users] Failed: phase compiling: libsidplay-1.36.59-1001 failed
Hi,
Fresh 10.9 fink installation with the binary distribution enabled
chokes on compiling libsidplay as follows:
g++ -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\
-DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libsidplay\
-DVERSION=\1.36.59\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_CHAR=1
-DSIZEOF_SHORT_INT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG_INT=8 -DSTDC_HEADERS=1
-DHAVE_LONG_FILE_NAMES=1 -DHAVE_DLFCN_H=1 -I. -I. -I.. -I/sw/include -g -O2 -MT
eeconfig.lo -MD -MP -MF .deps/eeconfig.Tpo -c eeconfig.cpp -fno-common -DPIC
-o .libs/eeconfig.o
sidtune.cpp:310:40: error: no member named 'bin' in 'std::__1::basic_ioschar'
ifstream myIn( fileName, ios::in|ios::bin|ios::ate );
~^
sidtune.cpp:976:50: error: no member named 'bin' in 'std::__1::basic_ioschar'
fMyOut.open( fileName, ios::out|ios::bin|ios::trunc );
~^
sidtune.cpp:1065:50: error: no member named 'bin' in 'std::__1::basic_ioschar'
fMyOut.open( fileName, ios::out|ios::bin|ios::trunc );
~^
3 errors generated.
I was under the impression that ios::bin is in fact ios::binary. To
confirm I did a test with this simple file:
#include iostream
#include fstream
using namespace std;
int main () {
ofstream myfile;
myfile.open(temp, ios::binary);
}
and it compiles fine with the stock clang++/g++. Yet the respective
test built into the configuration of the package does not think so:
checking whether standard member ios::binary is available... no
I am not sure how to fix this. Advice is appreciated. Many thanks.
Here is the system information:
Package manager version: 0.36.4.1
Distribution version: selfupdate-rsync Sat Apr 12 10:55:40 2014, 10.9, x86_64
Trees: local/main stable/main
Xcode.app: 5.1.1
Xcode command-line tools: 5.1.0.0.1.1396320587
Max. Fink build jobs: 3
Best regards,
Stefan
--
If it was so, it might be; and if it were so, it would be; but as it
isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
No HTML emails and proprietary attachments please http://bruda.ca/ascii
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Failed: phase compiling: libsidplay-1.36.59-1001 failed
On 12/04/14 18:59, Stefan Bruda wrote:
[]
I was under the impression that ios::bin is in fact ios::binary. To
confirm I did a test with this simple file:
#include iostream
#include fstream
using namespace std;
int main () {
ofstream myfile;
myfile.open(temp, ios::binary);
}
and it compiles fine with the stock clang++/g++. Yet the respective
test built into the configuration of the package does not think so:
checking whether standard member ios::binary is available... no
That configure script is 10 years old, from a time when iostream.h was
still a valid C++ header file. It does
#include iostream.h
#include fstream.h
and thinks the resulting error message about iostream.h not found means
ios::binary is not available. The fix is to patch the configure script
(or acinclude.m4 and then run autoreconf) so that it #includes the right
iostream and fstream headers.
--
Martin
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Failed: phase compiling: libsidplay-1.36.59-1001 failed
Hello,
At 21:59 +0200 on 2014-4-12 Martin Costabel wrote:
That configure script is 10 years old, from a time when iostream.h was
still a valid C++ header file. It does
#include iostream.h
#include fstream.h
and thinks the resulting error message about iostream.h not found means
ios::binary is not available. The fix is to patch the configure script
(or acinclude.m4 and then run autoreconf) so that it #includes the right
iostream and fstream headers.
Ah yes, I should have thought about this one... The following patch
does it for me, though I am not sure whether this is the best way to
go about it:
-- libsidplay.diff begins --
diff -Pur libsidplay-olde/libsidplay.info libsidplay/libsidplay.info
--- libsidplay-olde/libsidplay.info 2014-04-12 17:23:08.0 -0400
+++ libsidplay/libsidplay.info 2014-04-12 17:22:37.0 -0400
@@ -1,6 +1,8 @@
Package: libsidplay
Version: 1.36.59
-Revision: 1001
+Revision: 1002
+PatchFile: %n.patch
+PatchFile-MD5: ccfbfa50a0e36e5e40da75676fe596fd
GCC: 4.0
Depends: %N-shlibs (= %v-%r)
BuildDependsOnly: true
diff -Pur libsidplay-olde/libsidplay.patch libsidplay/libsidplay.patch
--- libsidplay-olde/libsidplay.patch1969-12-31 19:00:00.0 -0500
+++ libsidplay/libsidplay.patch 2014-04-12 17:22:37.0 -0400
@@ -0,0 +1,21 @@
+diff -Pur libsidplay-1.36.59-orig/configure libsidplay-1.36.59/configure
+--- libsidplay-1.36.59-orig/configure 2004-08-17 07:34:55.0 -0400
libsidplay-1.36.59/configure 2014-04-12 16:54:26.0 -0400
+@@ -2869,14 +2869,14 @@
+ cat conftest.$ac_ext _ACEOF
+ /* end confdefs.h. */
+
+-#include iostream.h
+-#include fstream.h
++#include iostream
++#include fstream
+
+ int
+ main ()
+ {
+
+-ifstream myTest(test,ios::in|ios::binary);
++std::ifstream myTest(test,std::ios::in|std::ios::binary);
+
+ ;
+ return 0;
-- libsidplay.diff ends --
Many thanks!
Cheers,
Stefan
--
If it was so, it might be; and if it were so, it would be; but as it
isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
No HTML emails and proprietary attachments please http://bruda.ca/ascii
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] botan-1.8.6-1 fails to build on 10.8
On Mon, 3 Mar 2014 18:01:47 -0500, Daniel Johnson
daniel.johnso...@gmail.com wrote:
On Mar 3, 2014, at 7:40 AM, Daniel Johnson
daniel.johnso...@gmail.com wrote:
On Mar 3, 2014, at 6:09 AM, Corey Halpin chal...@cs.wisc.edu wrote:
Unfortunately, I'm still on 10.7 and don't have a 10.8 machine to
test against.
I can get 1.10 (the upstream stable release) to mostly work on
10.7... however, Montone (the only package that uses botan that I
can find) doesn't build against botan 1.10 in any released
version. The monotone development branch does mention fixes for
compatibility with botan 1.10 -- but I'd need to be able to find
the relevant commit to backport it. More time to dig would be
required.
The use of configure.pl here was deliberate, as it supported
--cpu=generic. The newer configure.py forces one to choose a
specific architecture. Maybe this can be dropped now, as ppc
isn't really a concern?
By any chance does adding SetCPPFlags: -std=gnu89 resolve the issue?
I'll look into this more when I can, but I must apologize that
it probably won't be for a while. I'm preparing to defend my
dissertation and spare cycles are not abundant.
Best regards.
~crh
On 2014-02-28, Daniel Macks wrote:
g++ -Ibuild/include -O2 -finline-functions -D_REENTRANT -ansi
-Wno-long-long -fpermissive -W -Wall -fPIC -c src/block/aes/aes.cpp
-o build/lib/aes.o
clangclang: : warning: argument unused during compilation: '-fpermissive'
warning: argument unused during compilation: '-fpermissive'
In file included from src/block/aes/aes.cpp:8:
In file included from build/include/botan/aes.h:11:
In file included from build/include/botan/block_cipher.h:11:
In file included from build/include/botan/sym_algo.h:13:
In file included from build/include/botan/symkey.h:11:
build/include/botan/secmem.h:362:28: error: use of undeclared
identifier 'set'
{ if(this != in) set(in); return (*this); }
^
this-
build/include/botan/symkey.h:36:56: note: in instantiation of
member function
'Botan::SecureVector::operator=' requested here
void change(const MemoryRegion in) { bits = in; }
^
build/include/botan/secmem.h:146:12: note: must qualify
identifier to find this
declaration in dependent base class
void set(const T in[], u32bit n){ create(n); copy(in, n); }
^
build/include/botan/secmem.h:153:12: note: must qualify
identifier to find this
declaration in dependent base class
void set(const MemoryRegion in) { set(in.begin(), in.size()); }
^
1 error generated. make: *** [build/lib/aes.o] Error 1
Earlier during the build I noticed:
export PATH=/usr/bin:/usr/sbin:/bin:/sbin
./configure.pl --prefix=/sw --cpu=generic --docdir=/sw/share/doc
(warning): ./configure.pl is deprecated; migration to
./configure.py strongly recommended
And upstream is at 1.11, so there are lots of easy things to
upgrade that might fix the actual build failure (or at least let one
trouble-shoot a non-obsolete version, so that upstream can help fix
further). dan
---
Daniel Macks
dma...@netspace.org
I think I know how to fix it but it's going to take time I don't
have right now. Tonight I'll work on it. The code is using illegal
C++ that gcc happens to accept but clang (properly) rejects.
Daniel
Ok, the solution is to update to botan 1.8.14 which includes patches
for clang. I've successfully built it and tests pass on 10.9. I've
included the diff below. Unfortunately, monotone still doesn't build
on 10.9 since it requires non-standard features of gcc's libstdc++
and won't build with libc++. It also doesn't build with boost1.55 but
appears to work with 1.53.
Pushed this botan update. Built cleanly for me on 10.8 as well.
dan
--
Daniel Macks
dma...@netspace.org
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
