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
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.
I
-bit OS 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
OK.. I
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
-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 talking
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, not
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 off_t,
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
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
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
OK.. I think I'm sold (for 0.45
, 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, etc., to do
the right thing. I guess on Windows this would have to be somehow both
UTF8 and 64-bit safe - all
, 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(), fstat64() in place of
lseek() and fstat(). I
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,
-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 have
-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 __linux__
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 that,
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
, 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 then musician B
runs it and gets a crash instead
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 all
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
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
Darn, I just found there's a feature request for just that from IOhannes
pending since 2007.
https://sourceforge.net/tracker/index.php?func=detailaid=1638701group_id=55736atid=478073
Cheers,
--
Charles
Charles Goyard wrote:
Hi,
after some research, it seems more related to the size of the
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
26 matches
Mail list logo
