Hey all
I'm trying to cross-compile comport for Windows on Linux and stumbled across this error:
i686-w64-mingw32-gcc -DPD -I "/home/roman/.wine/drive_c/Pd//src/" -DMSW -DNT -o comport.o -c comport.c comport.c: In function ‘set_break’: comport.c:422:29: error: ‘nr’ undeclared (first use in this function) if (status != 0) return nr;
Interestingly, only the compiler that targets Windows complains about it. comport compiles fine for all Linux platforms I tried.
Without really understanding what the purpose of the parent function 'set_break' is, I went ahead and "fixed" line 422 to:
if (status != 0) return on;
I can now compile comport for Windows (and still for Linux) and the resulting binary loads fine, but I'm not able to judge whether this is a sensible fix. I simply tried to address what error message gave me without really knowing what I'm doing.
Can someone confirm that it was broken before this is the right way to address it?
I got comport from: http://git.puredata.info/cgit/svn2git/libraries/comport.git/
Thanks, Roman
On Sun, Feb 26, 2017 at 3:10 PM, Roman Haefeli reduzent@gmail.com wrote:
Hey all
I'm trying to cross-compile comport for Windows on Linux and stumbled across this error:
i686-w64-mingw32-gcc -DPD -I "/home/roman/.wine/drive_c/Pd//src/" -DMSW -DNT -o comport.o -c comport.c comport.c: In function ‘set_break’: comport.c:422:29: error: ‘nr’ undeclared (first use in this function) if (status != 0) return nr;
Interestingly, only the compiler that targets Windows complains about it. comport compiles fine for all Linux platforms I tried.
Without really understanding what the purpose of the parent function 'set_break' is, I went ahead and "fixed" line 422 to:
if (status != 0) return on;I can now compile comport for Windows (and still for Linux) and the resulting binary loads fine, but I'm not able to judge whether this is a sensible fix. I simply tried to address what error message gave me without really knowing what I'm doing.
Can someone confirm that it was broken before this is the right way to address it?
I got comport from: http://git.puredata.info/cgit/svn2git/libraries/comport.git/
That sounds familiar. I thought I already fixed that in sourceforge svn, maybe it didn't get copied to git or I forgot to actually commit?
I was working here: https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/iem/compor... Is this obsolete now?
Thanks, Roman
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Son, 2017-02-26 at 15:30 -0500, Martin Peach wrote:
On Sun, Feb 26, 2017 at 3:10 PM, Roman Haefeli reduzent@gmail.com wrote:
Hey all
I'm trying to cross-compile comport for Windows on Linux and stumbled across this error:
i686-w64-mingw32-gcc -DPD -I "/home/roman/.wine/drive_c/Pd//src/" -DMSW -DNT -o comport.o -c comport.c comport.c: In function ‘set_break’: comport.c:422:29: error: ‘nr’ undeclared (first use in this function) if (status != 0) return nr;
Interestingly, only the compiler that targets Windows complains about it. comport compiles fine for all Linux platforms I tried.
Without really understanding what the purpose of the parent function 'set_break' is, I went ahead and "fixed" line 422 to:
if (status != 0) return on;
I can now compile comport for Windows (and still for Linux) and the resulting binary loads fine, but I'm not able to judge whether this is a sensible fix. I simply tried to address what error message gave me without really knowing what I'm doing.
Can someone confirm that it was broken before this is the right way to address it?
I got comport from: http://git.puredata.info/cgit/svn2git/libraries/comport.git/
That sounds familiar. I thought I already fixed that in sourceforge svn,
Ah, yes, you did fix it the same way. Thanks.
maybe it didn't get copied to git or I forgot to actually commit?
No, I see now your commit in svn.
I was working here: https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/iem /comport/ Is this obsolete now?
There was a discussion on this list about moving to git back in October 2015 [1]. As a result, IOhannes made a snapshot of svn and provided everything as separate read-only git repositories. For many this is convenient, since they are now able to work on specific externals without requesting write access to the centralized subversion repository.
I'm about to make a proper pduino release and Deken packages thereof. I noticed that there is no comport (which is a dependency of pduino) release yet in Deken (besides the transitional Pd-extended import) and thus decided to make a release of it. In order to make things easier for myself, I decided to change the build system of everything I touch to Katja's pd-lib-builder and this is why I host my own git fork of comport [2].
I see you fixed even more for Windows than what I did. I would like to integrate your changes, but there are some questions left. The svn log suggests that you applied some changes specifically for Windows 10. In the diff, I see you wrapped some lines of code in:
#ifdef _MSC_VER
If I understand correctly, those lines are only used when compiling with Microsoft Visual Studio and mingw wouldn't use those lines. I'm compiling with mingw and would like the result to work will in Windows 10, too. Now, my question is: Should the code you put in between '#ifdef _MSC_VER' always be used when targeting Windows, regardless of the compiler or is that code really specific for MSVC?
Thanks, Roman
[1]: https://lists.puredata.info/pipermail/pd-dev/2015-10/020399.html [2]: https://github.com/reduzent/pd-comport
On Mon, 2017-02-27 at 10:28 +0100, Roman Haefeli wrote:
On Son, 2017-02-26 at 15:30 -0500, Martin Peach wrote:
On Sun, Feb 26, 2017 at 3:10 PM, Roman Haefeli reduzent@gmail.com wrote:
Hey all
I'm trying to cross-compile comport for Windows on Linux and stumbled across this error:
i686-w64-mingw32-gcc -DPD -I "/home/roman/.wine/drive_c/Pd//src/" -DMSW -DNT -o comport.o -c comport.c comport.c: In function ‘set_break’: comport.c:422:29: error: ‘nr’ undeclared (first use in this function) if (status != 0) return nr;
Interestingly, only the compiler that targets Windows complains about it. comport compiles fine for all Linux platforms I tried.
Without really understanding what the purpose of the parent function 'set_break' is, I went ahead and "fixed" line 422 to:
if (status != 0) return on;
I can now compile comport for Windows (and still for Linux) and the resulting binary loads fine, but I'm not able to judge whether this is a sensible fix. I simply tried to address what error message gave me without really knowing what I'm doing.
Can someone confirm that it was broken before this is the right way to address it?
I got comport from: http://git.puredata.info/cgit/svn2git/libraries/comport.git/
That sounds familiar. I thought I already fixed that in sourceforge svn,
Ah, yes, you did fix it the same way. Thanks.
maybe it didn't get copied to git or I forgot to actually commit?
No, I see now your commit in svn.
I was working here: https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/i em /comport/ Is this obsolete now?
There was a discussion on this list about moving to git back in October 2015 [1]. As a result, IOhannes made a snapshot of svn and provided everything as separate read-only git repositories. For many this is convenient, since they are now able to work on specific externals without requesting write access to the centralized subversion repository.
I'm about to make a proper pduino release and Deken packages thereof. I noticed that there is no comport (which is a dependency of pduino) release yet in Deken (besides the transitional Pd-extended import) and thus decided to make a release of it. In order to make things easier for myself, I decided to change the build system of everything I touch to Katja's pd-lib-builder and this is why I host my own git fork of comport [2].
Now, I wonder whether I rather should host the git forks of those externals under the umbrella of the pure-data group than under my personal 'reduzent' account. What do you think?
I'd like to contribute in a meaningful manner with causing as little mess as possible.
Roman
On 2017-02-27 10:59, Roman Haefeli wrote:
Now, I wonder whether I rather should host the git forks of those externals under the umbrella of the pure-data group than under my personal 'reduzent' account. What do you think?
I'd like to contribute in a meaningful manner with causing as little mess as possible.
i (with my iem hat on) was thinking about re-appropriating comport into the iem git repository, and giving anybody interested write access. alternatively we could host it on github.com/pure-data/ i'd rather not have the official repo in somebodies private repo (on github or otherwise).
gamsdr IOhannes
On Mon, 2017-02-27 at 11:02 +0100, IOhannes m zmoelnig wrote:
On 2017-02-27 10:59, Roman Haefeli wrote:
Now, I wonder whether I rather should host the git forks of those externals under the umbrella of the pure-data group than under my personal 'reduzent' account. What do you think?
I'd like to contribute in a meaningful manner with causing as little mess as possible.
i (with my iem hat on) was thinking about re-appropriating comport into the iem git repository, and giving anybody interested write access. alternatively we could host it on github.com/pure-data/
Whatever you think is appropriate. And yes, I'd like to request write access or a means to provide pull requests to what the home of comport is going to be.
i'd rather not have the official repo in somebodies private repo (on github or otherwise).
Sure.
Roman
On 2017-02-27 11:14, Roman Haefeli wrote:
On Mon, 2017-02-27 at 11:02 +0100, IOhannes m zmoelnig wrote:
On 2017-02-27 10:59, Roman Haefeli wrote:
Now, I wonder whether I rather should host the git forks of those externals under the umbrella of the pure-data group than under my personal 'reduzent' account. What do you think?
I'd like to contribute in a meaningful manner with causing as little mess as possible.
i (with my iem hat on) was thinking about re-appropriating comport into the iem git repository, and giving anybody interested write access. alternatively we could host it on github.com/pure-data/
Whatever you think is appropriate. And yes, I'd like to request write access or a means to provide pull requests to what the home of comport is going to be.
so this is to announce the new official home of [comport]:
to get write-access, please log into the system with your github/google/... account and do an explicit access-request (either via the webform of drop me an email; i can only add people that are known to the system - that is: they have logged in at least once).
(this is especially targetted at roman and martin)
fgmasdr IOhannes
On Mon, 2017-02-27 at 11:22 +0100, IOhannes m zmoelnig wrote:
On 2017-02-27 11:14, Roman Haefeli wrote:
On Mon, 2017-02-27 at 11:02 +0100, IOhannes m zmoelnig wrote:
On 2017-02-27 10:59, Roman Haefeli wrote:
Now, I wonder whether I rather should host the git forks of those externals under the umbrella of the pure-data group than under my personal 'reduzent' account. What do you think?
I'd like to contribute in a meaningful manner with causing as little mess as possible.
i (with my iem hat on) was thinking about re-appropriating comport into the iem git repository, and giving anybody interested write access. alternatively we could host it on github.com/pure-data/
Whatever you think is appropriate. And yes, I'd like to request write access or a means to provide pull requests to what the home of comport is going to be.
so this is to announce the new official home of [comport]:
to get write-access, please log into the system with your github/google/... account and do an explicit access-request (either via the webform of drop me an email; i can only add people that are known to the system - that is: they have logged in at least once).
(this is especially targetted at roman and martin)
Ok, I requested access.
Now, are you OK at all with me converting the build system to pd-lib- builder?
Roman
On 2017-02-27 11:36, Roman Haefeli wrote:
On Mon, 2017-02-27 at 11:22 +0100, IOhannes m zmoelnig wrote:
Ok, I requested access.
Now, are you OK at all with me converting the build system to pd-lib- builder?
go ahead from my side.
fgasdmr Ihannes
On Mon, 2017-02-27 at 11:02 +0100, IOhannes m zmoelnig wrote:
On 2017-02-27 10:59, Roman Haefeli wrote:
Now, I wonder whether I rather should host the git forks of those externals under the umbrella of the pure-data group than under my personal 'reduzent' account. What do you think?
I'd like to contribute in a meaningful manner with causing as little mess as possible.
i (with my iem hat on) was thinking about re-appropriating comport into the iem git repository, and giving anybody interested write access. alternatively we could host it on github.com/pure-data/
Only now I notice that there are _two_ Pd groups on github:
https://github.com/pure-data/ https://github.com/pd-projects
What is the purpose of each? Or did they happen just by accident?
Roman
On Mon, Feb 27, 2017 at 4:28 AM, Roman Haefeli reduzent@gmail.com wrote:
...
I see you fixed even more for Windows than what I did. I would like to integrate your changes, but there are some questions left. The svn log suggests that you applied some changes specifically for Windows 10. In the diff, I see you wrapped some lines of code in:
#ifdef _MSC_VER
If I understand correctly, those lines are only used when compiling with Microsoft Visual Studio and mingw wouldn't use those lines. I'm compiling with mingw and would like the result to work will in Windows 10, too. Now, my question is: Should the code you put in between '#ifdef _MSC_VER' always be used when targeting Windows, regardless of the compiler or is that code really specific for MSVC?
It's used to specify the use of sprintf_s() and strncpy_s(), the safer versions of sprintf() and strncpy(). If your compiler knows about these functions it would be better to use them, but not essential.
Martin
On Mon, 2017-02-27 at 14:19 -0500, Martin Peach wrote:
On Mon, Feb 27, 2017 at 4:28 AM, Roman Haefeli reduzent@gmail.com wrote:
...
I see you fixed even more for Windows than what I did. I would like to integrate your changes, but there are some questions left. The svn log suggests that you applied some changes specifically for Windows 10. In the diff, I see you wrapped some lines of code in:
#ifdef _MSC_VER
If I understand correctly, those lines are only used when compiling with Microsoft Visual Studio and mingw wouldn't use those lines. I'm compiling with mingw and would like the result to work will in Windows 10, too. Now, my question is: Should the code you put in between '#ifdef _MSC_VER' always be used when targeting Windows, regardless of the compiler or is that code really specific for MSVC?
It's used to specify the use of sprintf_s() and strncpy_s(), the safer versions of sprintf() and strncpy(). If your compiler knows about these functions it would be better to use them, but not essential.
I see. Thanks for the heads-up.
Roman
-
IOhannes m zmoelnig -
Martin Peach -
Roman Haefeli