As an aside, I'm also wondering what precautions I should take to make sure I don't violate the tools' license as regards distributing it with my code.
| Author | Comment | ||
|---|---|---|---|
cajunluke |
Tools Suite Compilation Questions |
Lead | |
|
I'm trying to compile the Tools Suite on my Mac for use with an eBook Generator program I'm writing. When I compile the tools, I get warnings about
pointer targets differing in signedness. I'm using gcc 4.0, the default in 10.5 (Leopard). I get the same results whether compiling through Xcode or using
the makelinux.sh (I have the results of the makelinux.sh if that would be helpful).
As an aside, I'm also wondering what precautions I should take to make sure I don't violate the tools' license as regards distributing it with my code. |
|||
Lionel Debroux |
|||
|
There's a greater problem than that warning in TIGCC Tools Suite 1.30 and below: the code is not 64-bit clean. It needs several changes to be correct on
64-bit platforms.
While the compiler is right, the "pointer target types differ in signedness" warning is, most of the time, just an annoyance. IIRC, these warnings were fixed at the same time as 64-bit architecture compatibility. What tools would you like to redistribute ? I'm asking because the license of several programs in the TIGCC Tools Suite was not changed yet to LGPL or wxWidgets' license, but maybe none of those is among the programs that you want to redistribute. |
|||
cajunluke |
|||
|
I'm using version 1.31 of the tools suite, but I'm not sure if I'm compiling for 64-bit or not (I have a Core 2 Duo, so I could be, but I'm not
sure). I would prefer to compile it using Xcode so I have a x86/PPC Universal binary, as I'm (right now) targeting my eBook maker to both platforms.
Right now, I'm working with ttdos2ebk and its dependencies: revtools.h, strhead.h, ttarchive.h, ttdos2ebk.c, ttebkgen.c, tt.h, ttpack.c, ttsplit.c, ttstrip.c, ttarchive.c, ttebkmeta.h, ttunebk.c, ttversion.h, ttunpack.h, ttunpack.c, unpack.c, packhead.h, bin2oth.c. |
|||
cajunluke |
|||
|
I'm not very familiar with straight C, so can anyone help me make this 64-bit clean?
|
|||
Lionel Debroux |
|||
|
Some of the dependencies of ttdos2ebk (e.g. ttpack/ttunpack) have been relicensed.
For now, use the version you can download from at http://members.chello.at/gerhard.kofler/kevin/tts140/ . I'll send you the relicensed versions when you want to redistribute your program. |
|||
cajunluke |
|||
|
I replaced the old versions of the files with these new ones, but I'm getting the exact same errors. It now looks like Xcode and/or gcc 4.0 are being weird
about it. I know some C, but not much, so if you could tell me what's likely to be wrong, I could try to fix it.
|
|||
Lionel Debroux |
|||
|
As I wrote, the "pointer target type differs in signedness" warning is seldom a big issue. It's mostly safe to ignore it.
Next week-end, I'll try to work a bit on the TIGCC Tools Suite. |
|||
cajunluke |
|||
|
Hmmm… Now it doesn't give me those errors, but it has another one: "duplicate symbol _DataBuffer2OTHBuffer in ttarchive.o and bin2oth.o".
Now I really have no idea what's going on, but take your time; I'm not quite finished with the rest of the program yet (I'm still learning Cocoa). Thanks for your help in this. |
|||
Lionel Debroux |
|||
|
All files that you wrote about in post #2 of this topic have already been relicensed
I've uploaded a snapshot of TIGCC Tools Suite 1.40 at http://tict.ticalc.org/beta/tt14020080706.tar.bz2 . I've seen that the makelinux.sh script breaks the source files completely, I wonder if I'm not going to remove it partially or completely, since GCC has no problem with CRLF line endings... As for the build problem you're experiencing: while waiting for a compilation/test process to finish, I might try to reproduce it at work, where I have a Mac Mini on my desktop. Most Mac Mini at work are dual-booting MacOS X and Ubuntu, but I'm not _sure_ whether mine (which I seldom use, my own PC is more powerful and has a faster HDD) has MacOS X. |
|||
cajunluke |
|||
|
I'll replace the source files with the new ones to see if that undoes whatever makelinux.sh breaks.
If the Mac Mini you have has OS X with the dev tools installed, I can send you the entire Xcode project I've been using. Is the mini PowerPC or Intel? |
|||
Lionel Debroux |
|||
|
The Mac Minis at work are all Intel.
|
|||
cajunluke |
|||
|
The function DataBuffer2OTHBuffer is defined in bin2oth.c and used in ttarchive.c. I tried renaming it to see if it was another name conflict, but that
didn't help. It appears that the compiler thinks that the usage in ttarchive.c is an implicit definition.
If the minis are Intel, then they can run Tiger or Leopard. If they have Leopard, can you install the developer tools (developer.apple.com)? You'll have to make a (free) "Online" developer membership, and download the iPhone SDK (it's the betas of the latest version (3.1) for both Mac and iPhone, and they're a lot better than the old (3.0) version). |
|||
Lionel Debroux |
|||
|
> It appears that the compiler thinks that the usage in ttarchive.c is an implicit definition.
Strange. Even when given -Wimplicit-function-declaration (or -Wall, which implies it), GCC doesn't complain about an implicit declaration. > If they have Leopard, can you install the developer tools (developer.apple.com)? I'm not sure that my Mac Mini (which I seldom use) is running Leopard, and I'm not sure either that I know the root password of it. I cannot check right now: starting yesterday evening, I'm on holiday until the 20th. |
|||
Kevin Kofler |
|||
|
bin2oth.c is #included into ttarchive.c (yuck!), so you must not compile and link bin2oth.c into the executable. If you link both bin2oth.c and ttarchive.c,
you will get a duplicate symbol, because bin2oth.c is already #included into ttarchive.c.
|
|||
cajunluke |
|||
|
I'm not entirely certain how to do what you recommend. bin2oth.c is included in the project, but the only thing I #include in my main.c file is ttebkgen.c,
in which I have not changed any #include directives.
I first removed bin2oth.c from the project (but did not move the file). This still gave me trouble until I commented out my main.c file and made ttebkgen.c the main source file. (I thought I had to keep the main function in main.c. Turns out I don't.) Now it's giving me crap about PrintUsage in ttarchive.c and dos2ebk.c. < time passes > So I did a project search (after readding bin2oth.c) for the offending string (it flagged every PrintUsage in every file as duplicates). In renaming each file's PrintUsage function to something unique (PrintUsage1, PrintUsage2, etc.), I noticed that the usages are preprocessored out (#ifdef), but gcc seemed to be ignoring that. After several more like that, I figured the preprocessor or some #defines weren't being run and just replaced the files with fresh versions (and I totally removed the main.c that came with the project). It's now back to complaining about PrintUsage in ttdos2ebk.c and ttarchive.c. I think I'll make a backup copy of the project and go fuss with the preprocessor settings. |
|||
Kevin Kofler |
|||
|
The problem is clearly that the IDE you're using isn't coping with the structure of the TIGCC Tools Suite source code. Use the build scripts.
|
|||
cajunluke |
|||
|
When I use the makelinux.sh (the patched version) it gives lots of errors. I can send you the output of the command if that would be helpful.
|
|||
Lionel Debroux |
|||
|
As I wrote above, I've seen strange things with makelinux.sh too. I wonder if I'm not going to remove it partially or completely, since GCC has no
problem with CRLF line endings.
What happens if you replace cat -vte $j | sed 's/\^M\$//g' | sed 's/\^I/ /g' > ../../linuxsrc/$i/$jwith something along the lines of cp $j ../../linuxsrc/$i/$j |
|||
cajunluke |
|||
|
With the replacement, it works except for ttdos2ebk:
building ttdos2ebk.c ... ttdos2ebk.c: In function 'main': ttdos2ebk.c:507: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' It also complains when that file is included in ttebkgen. Here is the section the line is in: (the problem being the 'test' variable) if ((test = fread(buf1,size,1,fp)) != 1) { > fprintf(stderr,"ERROR: cannot read content of inputfile %s (%d)\n",infile,test); fclose(fp); free(buf1); free(buf2); return 1; } |
|||
Lionel Debroux |
|||
|
> With the replacement, it works except for ttdos2ebk: [...]
OK, so I've reworked the snippet surrounding the offending line and replaced it by just
for i in $directories
do
if [ -d src/$i ]; then
cp -R $i ../../linuxsrc/
fi
done
As for the warning, it's harmless. Adding '(int)' before 'test' on the offending fprintf line will make it go away, and won't yield incorrect code. [EDIT: formatting of the code snippet] |
|||
Kevin Kofler |
|||
As for the warning, it's harmless. It's not. It will break at least on ppc64: %d expects a 32-bit int, size_t is 64-bit, and as ppc64 is big-endian, that will result in the code printing 0 instead of the actual size. The size mismatch could also cause trouble on x86_64, though probably not in this particular context. |
|||