| Summary: | Build issue: ktorrent configure and link errors | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | non-core programs | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugwatch, darrella, kb9vqf, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Darrell
2013-04-19 17:05:22 CDT
Bumping to Critical and adding to R14.0.0 check list. None of the bin files are being packaged. I can't replicate this on my Ubuntu Raring test box. Did you set --with-no-undefined or a similar compiler flag? If so, that might be causing the failure. Can you confirm that this failure still occurs when built against TDE from the latest GIT sources? If so, please attach a full build log. Thanks! > Did you set --with-no-undefined or a similar compiler flag?
Nope. My ktorrent build script is unchanged.
I updated GIT this morning and built a new package set including ktorrent. Same set of failures. I don't know what changed after April 15, which was the last time I built ktorrent without incident.
Do you see the DISTCLEANFILES message?
Is ktorrent dependent upon having avahi and avahi-tqt installed? I do not have either installed and I noticed the following in the configure output: checking for avahi-client >= 0.6.10... checking for avahi-tqt >= 0.6.10... checking if apps should be compiled... yes I installed libdaemon and avahi, built avahi-tqt, and then built ktorrent. Same errors. Although the bin files are not in the final package, the binaries are compiled. I can see them in the build directory. Interesting. I added --enable-closure to the ktorrent configure options. The errors disappeared and the package built completely as expected. What changed after April 15 that could cause this? (In reply to comment #6) > Interesting. I added --enable-closure to the ktorrent configure options. The > errors disappeared and the package built completely as expected. What changed > after April 15 that could cause this? I don't know. I take it nothing changed in the way you were building packages near that date? If there is a way to set enable-closure by default I would recommend that be done and this report closed. Exactly what does --enable-closure do? Perhaps understanding that might provide a clue. I am marking this report as resolved in the R14.0.0 etherpad road map but I am leaving the report open here. That I have to use --enable-closure and nobody else does is peculiar (irritating! :-) ). As there is a work-around, I am downgrading here from Critical to Normal. If nothing obvious appears over the next several weeks then I'll close the report. According to comments, the bug is basically resolved. |