By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 2525 - Build issue: tdenetwork R14.0.1 tarball FTBFS on Slackware 14.1
Summary: Build issue: tdenetwork R14.0.1 tarball FTBFS on Slackware 14.1
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdenetwork (show other bugs)
Version: R14.0.1 [Trinity]
Hardware: Other Slackware 14
: P1 blocker
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2015-09-08 11:03 CDT by Darrell
Modified: 2015-10-15 14:28 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
R14.0.1 tdenetwork build log (1.87 MB, text/x-log)
2015-09-08 12:05 CDT, Darrell 		Details
proposed patch to solve a building issue with tdenetwork (395 bytes, patch)
2015-09-14 15:19 CDT, Simone Giustetti 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2015-09-08 11:03:14 CDT 
The failure message:

/dev/shm/tdenetwork/krdc/vnc/threads.cpp:113:10: error: 'class TQString' has no member named 'vsprintf'

I built a package set on July 24 from git and did not experience the failure.
Comment 1 Darrell 2015-09-08 12:05:03 CDT 
Created attachment 2564 [details]
R14.0.1 tdenetwork build log
Comment 2 Simone Giustetti 2015-09-14 15:19:46 CDT 
Created attachment 2569 [details]
proposed patch to solve a building issue with tdenetwork
Comment 3 Simone Giustetti 2015-09-14 15:27:00 CDT 
I experienced the same issue while building tdenetwork for the Raspberry Pi. Reading the man pages for tqt3-tqcstring and tqt3-tqstring I deduced both classes do not have a method named vsprintf, but one named sprintf which uses a call to vsprintf.

Replacing vsprintf with sprintf I was able to compile threads.cpp, build and install the package. I did not test the resulting binary however... too busy building the remaining packages :) .

The attached patch should fix the issue. Apply it in the tdenetwork source file root directory.

Hope this helps.

Cheers
Simone
Comment 4 Darrell 2015-09-16 11:41:57 CDT 
Thanks for the patch. Tim needs to speak up about this bug report. He is the one who rewrote all of the code.

Nobody using Debian, Ubuntu, or Fedora are complaining about the build failure. So something else is awry. I do not know why I did not see a build failure from the git sources just a few weeks earlier yet see the failure with the tarball.
Comment 5 Slávek Banko 2015-09-17 22:21:45 CDT 
As revealed on closer inspection, the problem has a different cause:

http://trinity-users.pearsoncomputing.net/?0::9092
Comment 6 Darrell 2015-10-09 15:00:03 CDT 
Sigh, would have been nice if something had been posted to this bug report that the R14.0.1 tdenetwork tarball had been updated Sept. 26.

Were any other tarball updated after the official Aug. 13 realease? When I visit http://tde-mirror.yosemite.net/trinity/releases/R14.0.1/downloads.html, which is where my browser is redirected when I access the tarball link in the TDE web site, I see no date stamps to inform me.

FWIW, the Sept. 26 R14.0.1 tdenetwork tarball does build. I suppose this bug report can be closed.
Comment 7 Slávek Banko 2015-10-15 14:28:05 CDT 
(In reply to Darrell from comment #6)
> Sigh, would have been nice if something had been posted to this bug report
> that the R14.0.1 tdenetwork tarball had been updated Sept. 26.
> 
> Were any other tarball updated after the official Aug. 13 realease? When I
> visit
> http://tde-mirror.yosemite.net/trinity/releases/R14.0.1/downloads.html,
> which is where my browser is redirected when I access the tarball link in
> the TDE web site, I see no date stamps to inform me.
> 
> FWIW, the Sept. 26 R14.0.1 tdenetwork tarball does build. I suppose this bug
> report can be closed.

Yes, the source tarballs were regenerated, so now are correct.
Tim will announce this later on the mailing-list.