chuck 1.2.1.2 still doesn't work on 64-bit linux
All, Has anyone been able to get version 1.2.1.2 to work on 64-bit linux, without 32-bit compat libraries? It builds fine for me but seg faults on nearly every example. michael
On Sun, Jul 20, 2008 at 1:42 PM, Michael Heuer
All,
Has anyone been able to get version 1.2.1.2 to work on 64-bit linux, without 32-bit compat libraries?
It builds fine for me but seg faults on nearly every example.
People really need to stop complaining about this and start offering to help fix it instead. Steve
2008/7/21 Stephen Sinclair
Has anyone been able to get version 1.2.1.2 to work on 64-bit linux, without 32-bit compat libraries?
It builds fine for me but seg faults on nearly every example.
People really need to stop complaining about this and start offering to help fix it instead.
Dear Steve, while I agree that involvement is better then simply "consuming" and indeed we depend on it, Michael's post sounded more like a description of symptoms and a request for help or pointers then like a "complaint" to me. We don't know whether he might be planning to help and used this post to see if somebody had already made a start. I'm fully behind what I believe was your intention; to encourage involvement, but I feel getting involved (in any way) is probably more accessible if we assume good intentions on the part of our fellow ChucKists. Michael, Are you implying you *did* get ChucK to run on 64 bit Linux using "32-bit compat libraries"? If so would it be possible for you to document this process? Say- on the WiKi? I don't run 64 bit Linux myself but I'm getting the impression, particularly on the forum, that some people are on 64 bit Linux and believe they can't ChucK on it at all. If I'm reading your post right your attempts at this could mean a lot to some of them. Yours, Kas.
On Mon, Jul 21, 2008 at 12:02 PM, Kassen
2008/7/21 Stephen Sinclair
: Has anyone been able to get version 1.2.1.2 to work on 64-bit linux, without 32-bit compat libraries?
It builds fine for me but seg faults on nearly every example.
People really need to stop complaining about this and start offering to help fix it instead.
Dear Steve,
while I agree that involvement is better then simply "consuming" and indeed we depend on it, Michael's post sounded more like a description of symptoms and a request for help or pointers then like a "complaint" to me. We don't know whether he might be planning to help and used this post to see if somebody had already made a start.
Sorry, just that this one keeps coming up, and is obviously a bug of interest to several people. But a topic like "chuck still doesn't work on 64-bit linux" sounds like someone wondering why it hasn't been fixed yet. And the answer is simply, "because no one's fixed it." Steve
2008/7/21 Stephen Sinclair
Sorry, just that this one keeps coming up, and is obviously a bug of interest to several people. But a topic like "chuck still doesn't work on 64-bit linux" sounds like someone wondering why it hasn't been fixed yet. And the answer is simply, "because no one's fixed it."
Yes, I see. Still, I didn't read Michael's post that way, I read it more as asking whether anybody has made any progress and implying Michael himself had at least had some results using compatibility drivers (which I think is news?). I think that even asking why something hasn't been fixed yet (though probably not in those exact words) can be a constructive thing and need not be a "complaint". For example; I have been asking from time to time why Philippe's results in getting a ASIO build haven't yet been merged into the main Windows version. To me that's not a complaint as such, there may be good reasons, for example for a long time there was no suitable test system at Princeton, there could be a lack of time. I think that in many cases figuring out where exactly we are stuck can lead to people helping to move things forward. In the case of ASIO there was a set of tests done with a relatively wide variety of ASIO-enabled soundcards, I don't think those tests would've been done as publicly and in that way if Ge hadn't pointed out ASIO was stuck partially because of a lack of testing systems. With Ge's move to Stanford this could have changed, we'll never know if nobody asks and if there are no requests it may be harder to place priorities. Because of this I didn't feel it was benefitial to describe this post as a "complaint"; I think we are all grateful for what *has* been done by those generously donating their time. Michael's post itself didn't strike me as particularly demanding (for lack of a better word) but I can see how the subject title could give that impression. Yours, Kas.
On Mon, Jul 21, 2008 at 1:29 PM, Kassen
2008/7/21 Stephen Sinclair
: Sorry, just that this one keeps coming up, and is obviously a bug of interest to several people. But a topic like "chuck still doesn't work on 64-bit linux" sounds like someone wondering why it hasn't been fixed yet. And the answer is simply, "because no one's fixed it."
Yes, I see. Still, I didn't read Michael's post that way, I read it more as asking whether anybody has made any progress and implying Michael himself had at least had some results using compatibility drivers (which I think is news?).
I think that even asking why something hasn't been fixed yet (though probably not in those exact words) can be a constructive thing and need not be a "complaint". For example; I have been asking from time to time why Philippe's results in getting a ASIO build haven't yet been merged into the main Windows version. To me that's not a complaint as such, there may be good reasons, for example for a long time there was no suitable test system at Princeton, there could be a lack of time.
I think that in many cases figuring out where exactly we are stuck can lead to people helping to move things forward. In the case of ASIO there was a set of tests done with a relatively wide variety of ASIO-enabled soundcards, I don't think those tests would've been done as publicly and in that way if Ge hadn't pointed out ASIO was stuck partially because of a lack of testing systems. With Ge's move to Stanford this could have changed, we'll never know if nobody asks and if there are no requests it may be harder to place priorities.
Because of this I didn't feel it was benefitial to describe this post as a "complaint"; I think we are all grateful for what *has* been done by those generously donating their time. Michael's post itself didn't strike me as particularly demanding (for lack of a better word) but I can see how the subject title could give that impression.
Yes, I intended to be blunt but not disrespectful. I agree with you, but the 64-bit problem is one that tends to come up quite frequently. So, sorry for my negative reply, here's a more positive response: Has anyone had any success making portions of ChucK 64-bit-ready? I think taking things one small chunk at a time might be the way to go, though that could be easier said than done. Steve
On Mon, Jul 21, 2008 at 1:09 PM, Stephen Sinclair
On Mon, Jul 21, 2008 at 1:29 PM, Kassen
wrote: 2008/7/21 Stephen Sinclair
: Sorry, just that this one keeps coming up, and is obviously a bug of interest to several people. But a topic like "chuck still doesn't work on 64-bit linux" sounds like someone wondering why it hasn't been fixed yet. And the answer is simply, "because no one's fixed it."
Yes, I see. Still, I didn't read Michael's post that way, I read it more as asking whether anybody has made any progress and implying Michael himself had at least had some results using compatibility drivers (which I think is news?).
I think that even asking why something hasn't been fixed yet (though probably not in those exact words) can be a constructive thing and need not be a "complaint". For example; I have been asking from time to time why Philippe's results in getting a ASIO build haven't yet been merged into the main Windows version. To me that's not a complaint as such, there may be good reasons, for example for a long time there was no suitable test system at Princeton, there could be a lack of time.
I think that in many cases figuring out where exactly we are stuck can lead to people helping to move things forward. In the case of ASIO there was a set of tests done with a relatively wide variety of ASIO-enabled soundcards, I don't think those tests would've been done as publicly and in that way if Ge hadn't pointed out ASIO was stuck partially because of a lack of testing systems. With Ge's move to Stanford this could have changed, we'll never know if nobody asks and if there are no requests it may be harder to place priorities.
Because of this I didn't feel it was benefitial to describe this post as a "complaint"; I think we are all grateful for what *has* been done by those generously donating their time. Michael's post itself didn't strike me as particularly demanding (for lack of a better word) but I can see how the subject title could give that impression.
Yes, I intended to be blunt but not disrespectful. I agree with you, but the 64-bit problem is one that tends to come up quite frequently. So, sorry for my negative reply, here's a more positive response:
Has anyone had any success making portions of ChucK 64-bit-ready? I think taking things one small chunk at a time might be the way to go, though that could be easier said than done.
I gave it a try with the last source release, by adjusting the size of the pointers in the main header file and fixing the compile errors. That worked on a few more examples than the binary that is built by default, but it still blew whenever certian library calls were made. Unfortunately I am not much of a C programmer, and threw out whatever I had accomplished before. If anyone who knows what they are doing wants to jump in, I would be very willing to help test it. As far as the 32-bit compat libs, I thought someone on Ubuntu-64 had gotten chuck to work? I don't have any of those on my machine (gentoo amd64/2008.0/no-multilib profile). michael
Michael Heuer wrote:
On Mon, Jul 21, 2008 at 1:09 PM, Stephen Sinclair
wrote: As far as the 32-bit compat libs, I thought someone on Ubuntu-64 had gotten chuck to work? I don't have any of those on my machine (gentoo amd64/2008.0/no-multilib profile).
All I can tell you is that I run Ubuntu Studio 64, and that ChucK is available on my platform as a pre-compiled package, so presumably somebody worked some magic somewhere. I haven't done anything with ChucK at all yet, though, so it could all be thoroughly broken for all I know. Usually, though, they don't put broken programs in the repositories. -- Darren
participants (4)
-
Darren Landrum
-
Kassen
-
Michael Heuer
-
Stephen Sinclair