On 03/16/2013 23:42, Miller Puckette wrote:
> It's in the source - but Pd has to be compiled with '_LARGEFILE64_SOURCE'
> defined for this to work. Through 0.43 the configure script I was using
> was checking for this somehow (too complicted for me to understand how).
>
> Anyhow, this is a bug al
So a quick (and perhaps stupid) question - can I just use
#idfef __linux__ to alias open to open64, etc? It works on my
x86_64 machine and on my Raspberry Pi so I'm guessing all modern
linuxes define an open64(). My main fear is that android might define
__linux__ but not open64() - anyone know a
Hi,
thanks for taking that up.
On my machine (archlinux, Linux 3.7.10-1-ARCH i686 GNU/Linux, glibc
2.17), changing the LARGEFILE define to __linux__ (or __gnu_linux__
yields:
git pull
./autogen.sh
./configure --prefix=/opt/pd-vanilla/git --enable-jack
make prefix=/opt/pd-vanilla-git
[...]
gcc -D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-03-18 11:18, Charles Goyard wrote:
> Hi,
>
> thanks for taking that up.
>
> On my machine (archlinux, Linux 3.7.10-1-ARCH i686 GNU/Linux,
> glibc 2.17), changing the LARGEFILE define to __linux__ (or
> __gnu_linux__ yields:
nonono.
you MUST
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-03-18 13:10, IOhannes m zmoelnig wrote:
> On 2013-03-18 11:18, Charles Goyard wrote:
>> Hi,
>
>> thanks for taking that up.
>
>> On my machine (archlinux, Linux 3.7.10-1-ARCH i686 GNU/Linux,
>> glibc 2.17), changing the LARGEFILE define to _
> the problem with that is, that s_path implements an API available for
> externals.
> if open_via_path() returns a filehandle for an LFS file, and the
> external has been compiled without LFS, the filehande will be
> incompatible. see [1] for a discussion.
>
> i guess the only clean way to solve
To answer Ico's question, the trouble I forsee is musician A gives
musician B a patch, containing compiled externs - and then musician B
runs it and gets a crash instead of music. Sub-optimal in my opinion :)
I now think that it should be OK to use open64() only in the file d_soundfile.c
and only
March 18, 2013 2:47 PM
> To: Ivica Ico Bukvic
> Cc: 'IOhannes m zmoelnig'; pd-list@iem.at
> Subject: Re: [PD] Large File Support on Linux
>
> To answer Ico's question, the trouble I forsee is musician A gives
> musician B a patch, containing compiled externs - and
Hi,
I am in favour of breaking binary compatibility and keeping the code
simple. People that compile their externals themselves can understand
and cope with it. Other people mostly won't notice.
My intuition is that if the LFS project was unable to provide a transparent
API in the first place, th
On further thought, I don't think it's even possible to change open_via_path()
to use open64() and maintain even source compatibility for externs - if
one of them calls lseek or fstat we're sunk - and I don't see any robust
way of aliasing those calls to lseek64() etc.
I'm now realizing too that I
On 03/20/2013 18:02, Miller Puckette wrote:
> On further thought, I don't think it's even possible to change open_via_path()
> to use open64() and maintain even source compatibility for externs - if
> one of them calls lseek or fstat we're sunk - and I don't see any robust
> way of aliasing those c
OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, etc., to do
the "right" thing. I guess on Windows this would have to be somehow both
UTF8 and 64-bit safe - all the more reason to do as you suggest and hide the
whole mes behind sys_this_and_that() variants.
I thought exactly the same
variants?
> -Original Message-
> From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
> Miller Puckette
> Sent: Wednesday, March 20, 2013 6:46 PM
> To: IOhannes m zmölnig
> Cc: pd-list@iem.at
> Subject: Re: [PD] Large File Support on Linux
>
>
list-boun...@iem.at] On Behalf Of
> > Miller Puckette
> > Sent: Wednesday, March 20, 2013 6:46 PM
> > To: IOhannes m zmölnig
> > Cc: pd-list@iem.at
> > Subject: Re: [PD] Large File Support on Linux
> >
> > OK.. I think I'm sold (for 0.45 :) on trying to get
Wednesday, March 20, 2013 9:21 PM
> To: Ivica Ico Bukvic
> Cc: 'IOhannes m zmölnig'; pd-list@iem.at
> Subject: Re: [PD] Large File Support on Linux
>
> I believe not - every extern that used open_bia_path0 would have to be
> fixed at the source level to use lseek64()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-03-21 04:22, Ivica Ico Bukvic wrote:
> Could one simply redefine lseek and fstat to use lseek64 and
> fstat64 instead and be done with it (again, assuming one is not
> concerned with backwards and/or x-platform compatibility)?
if you are talki
Hi,
Here's a small summary of what has to be done, from
http://users.suse.com/~aj/linux_lfs.html :
"
In a nutshell for using LFS you can choose either of the following:
Compile your programs with "gcc -D_FILE_OFFSET_BITS=64". This forces
all file access calls to use the 64 bit variants.
Ivica Ico Bukvic wrote:
> Also, in Linux is open64 safe for both 32-bit and 64-bit OS variants?
Yes, you don't have to switch back to open() on 64-bits systems. So
basically switching everything to the 64-bits variants works on most
Linux systems installed since about 2002/2003.
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-03-21 09:37, Charles Goyard wrote:
> Note than open_via_file returns int and not off_t, so the
> automagic stuff will fail.
that's wrong.
the declaration of open64 is:
> int open64(const char *pathname, int oflag,...);
so it returns an int, no
IOhannes m zmoelnig wrote:
> On 2013-03-21 09:37, Charles Goyard wrote:
> > Note than open_via_file returns int and not off_t, so the
> > automagic stuff will fail.
>
> that's wrong.
> the declaration of open64 is:
> > int open64(const char *pathname, int oflag,...);
> so it returns an int, not an
er Puckette
> > > Sent: Wednesday, March 20, 2013 6:46 PM
> > > To: IOhannes m zmölnig
> > > Cc: pd-list@iem.at
> > > Subject: Re: [PD] Large File Support on Linux
> > >
> > > OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, et
Never mind - it stopped after 74 seconds (instead of 450) - presumably 4GB
early. But I don't believe this has anything at all to do with my using open()
instead of open64() - apparently writesf~ put the wrong number in the
soundfile header.
cheers
Miller
On Sat, Mar 23, 2013 at 08:15:47PM -0700
Hi Miller,
Yes I am on 32bit linux. For what I understand on 64 bits Linux LFS is
out of the box. The problem stands only for 32 bits hosts it seems.
I can follow a branch on git and test for you if you wish.
Alternatively I recall there's debian package to host a 32 bits linux in
a 64 bits linu
No worries I'll just go crank up an old 32 bit linux box myself :)
M
On Sun, Mar 24, 2013 at 04:07:12PM +0100, Charles Goyard wrote:
> Hi Miller,
>
> Yes I am on 32bit linux. For what I understand on 64 bits Linux LFS is
> out of the box. The problem stands only for 32 bits hosts it seems.
>
>
Hi,
after some research, it seems more related to the size of the file after
all. I thought the problem was 32 bits files because it worked when I
converted them to 16 bits. But it was just the file size dropped under
2gb.
To sum up: a file over about 2Gb fails to open. This is related to how
Lin
Darn, I just found there's a feature request for just that from IOhannes
pending since 2007.
https://sourceforge.net/tracker/index.php?func=detail&aid=1638701&group_id=55736&atid=478073
Cheers,
--
Charles
Charles Goyard wrote:
> Hi,
>
> after some research, it seems more related to the size o
It's in the source - but Pd has to be compiled with '_LARGEFILE64_SOURCE'
defined for this to work. Through 0.43 the configure script I was using
was checking for this somehow (too complicted for me to understand how).
Anyhow, this is a bug all right - thanks for reporting it!
... and can you te
27 matches
Mail list logo