Description of problem: See bug 691420 Version-Release number of selected component (if applicable): 1.100.fc14 How reproducible: i386 and possibly virt. host only Steps to Reproduce: 1. nc localhost 22 Actual results: See bug 691420 Expected results: netcats connects to sshd
Hmm, looks like strtonum(), which is part of libbsd is somehow broken: -------------- $ nm -D /usr/lib/libbsd.so.0 | grep strtonum 05fc9640 T strtonum -------------- Maybe the old nc doesn't link to it, so it doesn't have that problem. Let's see: -------------- $ ldd /usr/bin/nc linux-gate.so.1 => (0x00a9a000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x007b2000) libc.so.6 => /lib/libc.so.6 (0x00574000) /lib/ld-linux.so.2 (0x00553000) -------------- Yeah, maybe it's a problem in that library.
(In reply to comment #1) > Hmm, looks like strtonum(), which is part of libbsd is somehow broken: > -------------- > $ nm -D /usr/lib/libbsd.so.0 | grep strtonum > 05fc9640 T strtonum > -------------- > > Maybe the old nc doesn't link to it, so it doesn't have that problem. Let's > see: > -------------- > $ ldd /usr/bin/nc > linux-gate.so.1 => (0x00a9a000) > libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x007b2000) > libc.so.6 => /lib/libc.so.6 (0x00574000) > /lib/ld-linux.so.2 (0x00553000) > -------------- > > Yeah, maybe it's a problem in that library. Yes, the old Fedora nc was patched to used glib. I dropped those patches with the 1.100 upgrade and linked it against libbsd. CC'ing libbsd owner.
Maybe the prototype of this function in your source doesn't match what libbsd has (these long long things in the argument list look awfully suspicious). So, maybe on 32-bits, this gets passed in as shorter then it should be or something.
Maybe you need to include <bsd/stdlib.h> or something...
(In reply to comment #4) > Maybe you need to include <bsd/stdlib.h> or something... That could be! :)
Stock netcat.c has #include <stdlib.h>. Now, pkgconfig --cflags libbsd does not return any -I paths at all. So, maybe that's the real problem.
pkgconfig --cflags doesn't return any -I paths by design, in order to prevent libbsd from overriding any of the standard systems libraries that you don't explicitly include using #include <bsd/foo.h>. I have generally found there to be much more breakage if pkgconfig returns -I/usr/include/bsd than if it returns nothing. This does in some cases require changing the include directives in the software being ported. If you really want to use libbsd rather than patching netcat to use glibc, then I would recommend changing the #include <stdlib.h> to #include <bsd/stdlib.h>. It is quite possible that strtonum is broken, which may as Bojan suggested be due to the use of long long. I'll investigate this when I get a chance, which may not be for a week or two. If long long really turns out to be the problem, I'll consider patching it to int64_t, and recommend that upstream.
The fix is then most likely to include stdlih.h from the bsd path explicitly. If the last build was done with warnings turned on, a missing prototype of the strtonum() would have been reported. We just need to look in koji logs.
Yeah, the log has implicit declaration of strtonum() and other functions. That's the problem. So, netcat.c should be patched to get headers from bsd. PS. There are other warnings in socks.c as well.
Ah, the C version of the old Fortran problem: "GOD IS REAL UNLESS DECLARED INTEGER". At this point I don't plan to take any action regarding libbsd unless it is still implicated in problems with netcat after the include is changed.
I am not familiar with libbsd at all, but if it's supposed to override/add stuff that doesn't exist in glibc, maybe returning -I wouldn't be such a bad idea. After all, the point is to be able to compile/link bsd specific programs without modification, right?
I don't think so. You might want to include other headers in libbsd, but not libbsd's stdlib.h. There was a debate over this stuff in the package review for libbsd, and it was concluded that where libbsd provided headers with the same name as existing non-libbsd headers, they should be in /usr/include/bsd and explicitly included as such, to distinguish them from the non-libbsd headers.
I should add that the intent was that libbsd ease porting BSD programs with minimal changes, avoiding ad hoc proliferation of reimplementations of BSD functions, but not necessarily with no changes to the ported code.
OK, thanks for the further explanation. I guess patching netcat.c and maybe some other files that are giving compilation warnings is the go then.
I hope it's ok to hijack this thread instead of opening a new problem report… It seems like something went wrong with the recent netcat update: $ nc otherhost 54321 < testfile nc: port number ������ ���: 54321 $ hm… this doesn't look right :( and yeah, that's it then, I can't use netcat anymore to send files etc. affected: nc-1.100-1.fc14.i686
Created attachment 491132 [details] Explictly use bsd/stdlib.h to avoid I've built this locally and it solved my problems with not being able to connect.
(In reply to comment #15) > I hope it's ok to hijack this thread instead of opening a new problem report… > > It seems like something went wrong with the recent netcat update: > > $ nc otherhost 54321 < testfile > nc: port number ������ > ���: 54321 > $ > > hm… this doesn't look right :( > > and yeah, that's it then, I can't use netcat anymore to send files etc. > > affected: nc-1.100-1.fc14.i686 Same issue. See https://bugzilla.redhat.com/show_bug.cgi?id=691420#c8 and below.
(In reply to comment #16) > Created attachment 491132 [details] > Explictly use bsd/stdlib.h to avoid > > I've built this locally and it solved my problems with not being able to > connect. Building netcat just like this emits a lot of (mostly signess related) warnings. This could introduce even more not so visible bugs. I'm currently looking for what libbsd header files we should include and what additional patching we should do. Currently, the best thing to do is to downgrade back to 1.84 until 1.100 is fixed.
(In reply to comment #18) > Currently, the best thing to do is to downgrade back to 1.84 until 1.100 is > fixed. Can you unpush the package from bodhi? No point keeping broken binaries.
(In reply to comment #19) > (In reply to comment #18) > > > Currently, the best thing to do is to downgrade back to 1.84 until 1.100 is > > fixed. > > Can you unpush the package from bodhi? No point keeping broken binaries. I'd rather push 1.100-2 with Tony's patch (basically), fixing at least this issue and have something working. Would you test it, please?
1.100-2 Koji builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=2992644
(In reply to comment #21) > 1.100-2 Koji builds: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2992644 Yeah, that works for me on F-14. Just a brief test that would otherwise fail with 100-1.
(In reply to comment #21) > 1.100-2 Koji builds: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2992644 Thanks! Works for me. When you make the update for f14 let me I'll happily add +1 karma
Thank you! The update is on its way...
nc-1.100-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nc-1.100-2.fc14
nc-1.100-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/nc-1.100-2.fc15
*** Bug 695571 has been marked as a duplicate of this bug. ***
Package nc-1.100-2.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nc-1.100-2.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/nc-1.100-2.fc14 then log in and leave karma (feedback).
*** Bug 695768 has been marked as a duplicate of this bug. ***
nc-1.100-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
nc-1.100-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.