| Summary: | net-analyzer/nam ~amd64 patch | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diogo Ferreira <diogo.ferreira> |
| Component: | New packages | Assignee: | AMD64 Project <amd64> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | robbat2 |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
nam-1.11-r1.ebuild
nam-amd64-intsize.patch nam-1.11-r1.ebuild nam-1.11-fix-address-size.patch x86_64 and GCC 4.1.1 patch |
||
|
Description
Diogo Ferreira
2006-10-02 12:22:45 UTC
Created attachment 98617 [details]
nam-1.11-r1.ebuild
Created attachment 98618 [details, diff]
nam-amd64-intsize.patch
Comment on attachment 98618 [details, diff]
nam-amd64-intsize.patch
This will break 32bit arches, as long long is 64bit there too. What you want is just 'long'.
(In reply to comment #3) > (From update of attachment 98618 [details, diff] [edit]) > This will break 32bit arches, as long long is 64bit there too. What you want is > just 'long'. > Did you even read the ebuild? You are right, but it wouldn't break 32bit archs because it was being applied only to amd64.. (In reply to comment #4) > Did you even read the ebuild? You are right, but it wouldn't break 32bit archs > because it was being applied only to amd64.. > Which is a bad method to apply patches :) No, I didn't read the ebuild (you marked it as application/octet-stream, was simply too much of an effort for me, and as I know how to apply patches I didn't bother anyway). However, we prefer to apply patches unconditionally whenever possible, which is the case here. Created attachment 99082 [details]
nam-1.11-r1.ebuild
Created attachment 99083 [details, diff]
nam-1.11-fix-address-size.patch
(In reply to comment #6) > No, I didn't read the ebuild (you marked it as application/octet-stream, was > simply too much of an effort for me, and as I know how to apply patches I > didn't bother anyway). However, we prefer to apply patches unconditionally > whenever possible, which is the case here. > Ok, sorry for submitting bad stuff, does it look good now? Comment on attachment 99083 [details, diff]
nam-1.11-fix-address-size.patch
I'm sorry, but this patch doesn't fix the issue either, it only makes nam compile fine. Fex the chunk in group.cc:81 casts it to long, but mbrs[] is a int[] array, so it will just get truncated at the next occation. Plus, the arguments to that function are given as int, then casted into a (const char *). The chunks in netmodel.cc cast a void * to a int/long, but I wonder why it is doing it in the first place. Also, the function is defined with return type int instead of long, but I really wonder why it is even casted to an int when it deals with pointers anyway. In short, this app is a mess, and requires a bit more work. It probably should have never gotten the ~amd64 keyword in the first place. As nothing depends on it, i marked it -amd64 for the time being. Patches are still welcome though :)
Created attachment 102189 [details, diff]
x86_64 and GCC 4.1.1 patch
This seems to be a TCL issue and nam just inherits it. If you declare NO_VOID for the nam compile everything works fine.
As for the (const char*) typecast, I dont know why it is done that way but I see a lot of TCL/Tk code do that.
Attached is a patch that cleans up for AMD and should work for i386 platforms also though I haven't tested it.
I will post the patch in the nam-developers list. It is diff'd against the latest CVS code of nam.
Can we please set it to ~amd64 if the patch works :)
Please reopen this bug once upstream has incorporated the patches. Sadly we don't have enough manpower to focus on packages that are not even marked ~amd64. |
