This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's
Technology & Calculator Open Topic subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.
Computer Tech Support =>
Technology & Calculator Open Topic
| Author |
Message |
|
seank
Newbie
Joined: 07 Sep 2010
Posts: 3
|
 Posted: 07 Sep 2010 04:41:45 pm Post subject: |
|
|
Hello:
I need some assistance. I have been banging my head for days just to try and get the TiLP SDK test programming running on Windows XP with MinGW. I have had nothing but problems with glib and various other errors trying to get just the test working. I hope that someone has the experience and can help me do this so I can start programming a small GUI based transfer and conversion program for the TI-84+ SE. Thanks for the assistance!
- Sean |
|
| Back to top |
|
|
Lionel Debroux
Member
Joined: 01 Aug 2009
Posts: 170
|
| Posted: 10 Sep 2010 01:08:15 am Post subject: |
|
|
Hello :)
Indeed, using MSYS + MinGW (instead of MSVC) to compile TILP under native Windows is a huge pain in the ..., as you've experienced yourself. And I'm saying that as the current maintainer of TILP + libraries.
In a more general sense, compiling autotools+libtool+pkgconfig -based software (many open source projects are) under native Windows with MSYS + MinGW tends to be hard (and slow), even more so if they have non-native dependencies (Glib, GTK+, Qt, etc.).
That's why I gave up on MSYS + MinGW after hours of trying, without ever having produced a working build. After making a first build with MSVC (which was easy enough), I switched to cross-compiling from my familiar Linux environment, using the mingw32 cross-compiler provided by my distro (all major distros provide one). After a little setup (which I documented somewhat, e.g. I committed my maintainer scripts to the TILP SVN repository  ), it Just Works (TM), and as a bonus, it's much faster than compilation with MSYS + MinGW on native Windows is (which takes three seconds for each line of the configure, etc. etc.).
To sum up: if you want to produce a working Windows build without spending even more days of gnashing of teeth (and up to several hours of compilation each time there's an update on the upstream code base...), I advise you to either use MSVC (the Express edition of Visual Studio is enough to compile TILP itself, so it's enough to compile libti*-using programs) or cross-compile from Linux. Both ways are tried and true :)
Lionel.
Last edited by Guest on 10 Sep 2010 06:22:31 am; edited 1 time in total |
|
| Back to top |
|
|
seank
Newbie
Joined: 07 Sep 2010
Posts: 3
|
| Posted: 12 Sep 2010 04:53:00 pm Post subject: |
|
|
Lionel:
Thanks for the reply! I been doing some work on Ubuntu to do work with TiLP. Do you have a suggested MSVC and Linux distro you find to work the best? Right now I am getting ticables warnings when trying to use the the test code to transfer the RDY command and receive a reply.
Thanks,
Sean
Lionel Debroux wrote:
Hello :)
Indeed, using MSYS + MinGW (instead of MSVC) to compile TILP under native Windows is a huge pain in the ..., as you've experienced yourself. And I'm saying that as the current maintainer of TILP + libraries.
In a more general sense, compiling autotools+libtool+pkgconfig -based software (many open source projects are) under native Windows with MSYS + MinGW tends to be hard (and slow), even more so if they have non-native dependencies (Glib, GTK+, Qt, etc.).
That's why I gave up on MSYS + MinGW after hours of trying, without ever having produced a working build. After making a first build with MSVC (which was easy enough), I switched to cross-compiling from my familiar Linux environment, using the mingw32 cross-compiler provided by my distro (all major distros provide one). After a little setup (which I documented somewhat, e.g. I committed my maintainer scripts to the TILP SVN repository ), it Just Works (TM), and as a bonus, it's much faster than compilation with MSYS + MinGW on native Windows is (which takes three seconds for each line of the configure, etc. etc.).
To sum up: if you want to produce a working Windows build without spending even more days of gnashing of teeth (and up to several hours of compilation each time there's an update on the upstream code base...), I advise you to either use MSVC (the Express edition of Visual Studio is enough to compile TILP itself, so it's enough to compile libti*-using programs) or cross-compile from Linux. Both ways are tried and true :)
Lionel.
|
|
| Back to top |
|
|
Lionel Debroux
Member
Joined: 01 Aug 2009
Posts: 170
|
| Posted: 13 Sep 2010 12:30:09 pm Post subject: |
|
|
Quote: Do you have a suggested MSVC and Linux distro you find to work the best?
I'd say that the MSVC version is largely indifferent: Romain used MSVC 6 for years, I converted the project files to VS 2008 Express when I made my first Windows TILP build as a maintainer and IIRC, I just had to make one minor change. I never got around to committing the new project files, IIRC I booted my Seven x64 VM at most once since then...
As for *nix: a while ago, I made and improved over time sh scripts that compile libti*+gfm+tilp and libti*+tiemu:
http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh
http://lpg.ticalc.org/prj_tiemu/downloads/install_tiemu.sh
So far, these scripts (especially the first one) have been reported to yield working binaries on Debian Lenny; multiple versions of Ubuntu; Arch; Fedora 12 |
|
| Back to top |
|
|
FloppusMaximus
Advanced Member
Joined: 22 Aug 2008
Posts: 472
|
| Posted: 13 Sep 2010 10:11:45 pm Post subject: |
|
|
| As I understand it: There are quite a number of different C runtime libraries used on Windows. GLib and GTK+ always used to be, and as far as I know still are, linked against msvcrt.dll, which is the default C library used by both MinGW and Visual Studio 6. (msvcrt.dll is old, but works; it does everything you want it to, and it's been pre-installed in every version of Windows this decade.) Newer versions of Visual Studio use newer C libraries by default, though I assume there's still an option buried somewhere to change it. I don't know whether there are any real problems with using different C libraries for different modules (e.g., are the malloc() implementations compatible? are the fopen() implementations compatible?) but it seems wise to avoid doing that if you can. |
|
| Back to top |
|
|
seank
Newbie
Joined: 07 Sep 2010
Posts: 3
|
| Posted: 14 Sep 2010 12:38:55 pm Post subject: |
|
|
| Thanks guys I will keep at it! |
|
| Back to top |
|
|
|
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
