Opened 12 years ago

Closed 12 years ago

#1682 closed Enhancement (wontfix)

Build System support for Haiku

Reported by: mmadia Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.42
Severity: Normal Keywords:
Cc:

Description

Haiku is an open-source implementation of BeOS R5, with some enhancements.

Attached is a patch for extending Transmission's build system to allow compiling of the CLI and Daemon for Haiku. This does not include updating the BeOS GUI client(from <1.0) to work with the newer libtransmission.

Build instructions are attached as well.

Another location for possible future patches, instructions, and binaries is http://ports.haiku-files.org/wiki/net-p2p/transmission

Attachments (4)

transmission-1.42-haiku-rev2.diff (11.7 KB) - added by mmadia 12 years ago.
initial patch for supporting Haiku
BuildInstructions.Haiku (352 bytes) - added by mmadia 12 years ago.
transmission-1.42-haiku-gcc2-rev4.diff (6.7 KB) - added by mmadia 12 years ago.
Updated patch for Haiku gcc2
transmission-svn8039-haiku-gcc2-r29322-rev1.diff (11.5 KB) - added by mmadia 12 years ago.
Initial and incomplete patch for building svn in Haiku gcc2

Download all attachments as: .zip

Change History (22)

Changed 12 years ago by mmadia

initial patch for supporting Haiku

Changed 12 years ago by mmadia

comment:1 Changed 12 years ago by mmadia

Individual patches have been sent to the maintainers of libevent and libnatpmp.

libgen.h support has been added to Haiku in rev28888.

Aside from the 3rdparty changes, libtransmission/platform.c seems to be the only change needed.

In a few days, I will prepare a new patch.

comment:2 Changed 12 years ago by charles

Sounds great; I'll look forward to seeing it.

If possible, could you please apply the patch to 1.50 (or a 1.50 beta) instead of 1.42? Thank you.

comment:3 Changed 12 years ago by mmadia

There's a few issues with Haiku on trunk/1.5x

  • IPv6 is at best incomplete
  • GCC4 is possible, but not enabled by default. However, the gcc4 to gcc2 changes are trivial and mostly include modifying configure.ac to remove certain CFLAGS.

My initial portlog attempt of Transmission revision 7652 can be found at: http://ports.haiku-files.org/wiki/net-p2p/transmission/svn7652

Below are the guts of it, after applying the changes needed for 1.42

remove from configure.ac :

-Wextra -Winit-self -Wmissing-format-attribute -std=gnu99

At this point, make will complain about : libtransmission/net.c:56: `IN6ADDR_ANY_INIT' undeclared here (not in a function

For fixing it, the best I know so far is : in libtransmission/net.h add: #if defined(HAIKU) #include <resolv.h> #endif

However that'll generate some more errors: /boot/develop/headers/posix/resolv.h:160: field `nsaddr_list' has incomplete type /boot/develop/headers/posix/resolv.h:170: field `addr' has incomplete type /boot/develop/headers/posix/resolv.h:194: field `sin' has incomplete type transmission-1.42+-svn7652/libtransmission/bandwidth.c: In function `tr_bandwidthAllocate': transmission-1.42+-svn7652/libtransmission/bandwidth.c:228: warning: unknown conversion type character `z' in format transmission-1.42+-svn7652/libtransmission/bandwidth.c:228: warning: too many arguments for format make[2]: * [bandwidth.o] Error 1 make[2]: Leaving directory `transmission-1.42+-svn7652/libtransmission'

Here is a link to Haiku's <resolv.h> : http://svn.berlios.de/wsvn/haiku/haiku/trunk/headers/posix/resolv.h

Now, continuing from that port log,

replacing %zd with %d in libtransmission/bandwidth.c:228 , produces this warning: libtransmission/bandwidth.c:231: warning: int format, ssize_t arg (arg 7) (line 231 being the updated dbgmsg command) But, bandwidth.c still fails to compile due to the issues mentioned in the portlog.

As I've mentioned earlier, my C/C++ abilities aren't developed enough to tackle these issues.

comment:4 Changed 12 years ago by mmadia

Here is a screenshot of 1.42's WebClient? running in Bon Echo 2.0.0.x (an unofficial Firefox release) in Haiku : http://noob.hu/07/0112/Transmission_Haiku.jpg

I have released a binary package, which includes the cli, -daemon, -remote, web/, all UPPERCASE text files, my patch, and build instructions : http://www.haikuware.com/view-details/development/app-installation/transmission-142 One minor issue is that I did not identify pre-existing shared libraries that were linked in dynamically. These include, but may not be limited to intltool and iconv.

comment:5 Changed 12 years ago by charles

mmadia: has any progress been made on this ticket?

comment:6 Changed 12 years ago by charles

Update in irc:

14:06 < mmadia> charles_  :  i've been meaning to update the 1.42 for Haiku patch.   I could make a newer one for trunk, but since Haiku won't be getting IPv6 for a while, I doubt it'll build.
14:07 <@charles_> mmadia: hmmmm
14:08 <@charles_> mmadia: what would be the best way to handle post-1.42?
14:08 < mmadia> just to note charles_ , my coding abilites are no where near good enough to either implement it in haiku or to refactor transmission's code to handle both ipv6 and ipv4.
14:09 < mmadia> I'll ask a few devs for their input on that, charles_

Changed 12 years ago by mmadia

Updated patch for Haiku gcc2

Changed 12 years ago by mmadia

Initial and incomplete patch for building svn in Haiku gcc2

comment:7 Changed 12 years ago by mmadia

Build dependencies: http://ports.haiku-files.org/wiki/net-p2p/transmission/1.42

Build commands:

wget http://ports.haiku-files.org/svn/haikuports/trunk/net-p2p/transmission/transmission-svn8039-haiku-gcc2-r29322-rev1.diff
patch -p1 -i transmission-svn8039-haiku-gcc2-r29322-rev1.diff
libtoolize --force --copy --install
autoreconf --force --install -I config -I m4
configure --prefix=/boot/common LDFLAGS=-lnetwork
make

Initial errors after build commands:

transmission-1.51+/libtransmission/net.c:56: `IN6ADDR_ANY_INIT' undeclared here (not in a function)
transmission-1.51+/libtransmission/net.c:183: `INET6_ADDRSTRLEN' undeclared (first use in this function)
transmission-1.51+/libtransmission/net.c:212: warning: implicit declaration of function `IN6_IS_ADDR_V4MAPPED'
transmission-1.51+/libtransmission/net.c:469: warning: implicit declaration of function `IN6_IS_ADDR_LINKLOCAL'

For fixing it, the best I know so far is adding : libtransmission/net.h

#if defined(HAIKU)
#include <resolv.h>
#endif

Haiku's posix/resolv.h :
http://dev.haiku-os.org/browser/haiku/trunk/headers/posix/resolv.h
Since this header is incomplete at best, only more errors ensue:

make[2]: Entering directory `/misc_obj/transmission-1.51+/libtransmission'
source='bandwidth.c' object='bandwidth.o' libtool=no \
        DEPDIR=.deps depmode=gcc /bin/sh ../depcomp \
        gcc -DPACKAGE_NAME=\"transmission\" -DPACKAGE_TARNAME=\"transmission\" -DPACKAGE_VERSION=\"1.51+\" -DPACKAGE_STRING=\"transmission\ 1.51+\" -DPACKAGE_BUGREPORT=\"http://trac.transmissionbt.com/newticket\" -DPACKAGE=\"transmission\" -DVERSION=\"1.51+\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DTR_NIGHTLY_RELEASE=1 -DSTDC_HEADERS=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LRINTF=1 -DHAVE_STRLCPY=1 -DHAVE_DIRNAME=1 -DHAVE_BASENAME=1 -DHAVE_STRCASECMP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_PTHREAD=1 -DHAVE__TMP_DUMMY1_ZLIB_H=1 -DHAVE_ZLIB=1 -DHAVE_DECL_POSIX_FADVISE=0 -Dva_copy=__va_copy -DHAVE_LIBINTL_H=1 -DGETTEXT_PACKAGE=\"transmission\" -DHAVE_LOCALE_H=1 -DHAVE_LC_MESSAGES=1 -DHAVE_BIND_TEXTDOMAIN_CODESET=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -DENABLE_NLS=1 -I.  -I. -I.. -I../third-party/ -D__TRANSMISSION__ -I../third-party/libevent -DPACKAGE_DATA_DIR=\""/boot/common/share"\"  -I/boot/common/include   -I/boot/common/include     -g -O2 -g -O0 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wwrite-strings -c bandwidth.c
In file included from /misc_obj/transmission-1.51+/libtransmission/utils.h:19,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.h:22,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.c:19:
/boot/develop/headers/bsd/stdio.h:16: warning: redundant redeclaration of `fgetln' in same scope
/boot/develop/headers/posix/stdio.h:138: warning: previous declaration of `fgetln'
In file included from /misc_obj/transmission-1.51+/libtransmission/utils.h:20,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.h:22,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.c:19:
/boot/develop/headers/posix/string.h:74: warning: redundant redeclaration of `strsignal' in same scope
/boot/develop/headers/posix/signal.h:177: warning: previous declaration of `strsignal'
In file included from /misc_obj/transmission-1.51+/libtransmission/utils.h:21,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.h:22,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.c:19:
/boot/develop/headers/bsd/stdlib.h:16: warning: redundant redeclaration of `daemon' in same scope
/boot/develop/headers/posix/stdlib.h:63: warning: previous declaration of `daemon'
In file included from /misc_obj/transmission-1.51+/libtransmission/net.h:33,
                 from /misc_obj/transmission-1.51+/libtransmission/peer-io.h:31,
                 from /misc_obj/transmission-1.51+/libtransmission/bandwidth.c:21:
/boot/develop/headers/posix/resolv.h:160: field `nsaddr_list' has incomplete type
/boot/develop/headers/posix/resolv.h:170: field `addr' has incomplete type
/boot/develop/headers/posix/resolv.h:194: field `sin' has incomplete type
make[2]: *** [bandwidth.o] Error 1
make[2]: Leaving directory `/misc_obj/transmission-1.51+/libtransmission'

At this point, I'm waiting to here back from other Haiku developers with a stronger c/c++ background on some possible courses of action. Though I have doubts that any current core developer will devote time to implementing IPv6, especially as the focus is on getting R1/alpha1 out the door.

comment:8 Changed 12 years ago by livings124

Just a note: you shouldn't be sending us patches to miniupnp and libnat. Those are third-party frameworks and patches should be sent to http://miniupnp.tuxfamily.org/.

comment:9 Changed 12 years ago by livings124

Also, don't bother sending in patches for anything other than current trunk. We won't be touching 1.42 code, or even 1.5 code for that matter.

comment:10 Changed 12 years ago by livings124

And patches to libevent go to the libevent developers at http://www.monkey.org/~provos/libevent/

comment:11 Changed 12 years ago by mmadia

My apologies. I understand 1.42 and other 'tag' releases are essentially frozen. My rationale for the 1.42 patch is more for record keeping in case someone decides to build a version of Transmission for Haiku. I have indeed sent the 3rd party patches upstream and at least libevent has committed them. Miniupnp rejected the patch, as it was a complete hack and not a proper implementation, which is understandable.

Would it be better to set this ticket as Closed-->Won't fix and create a new ticket for svn patches?

comment:12 Changed 12 years ago by livings124

I'm going to have to agree with the hackiness. Perhaps this should be closed and we should wait for haiku to be a little more mature?

comment:13 Changed 12 years ago by mmadia

To sum up irc between livings124 and myself:

livings124: looking at the code's comments, it also looks like the hack is because "its network stack is not yet feature complete."
mmadia: That may not have been the best wording on my part.  I'll try to have some haiku devs look at the miniupnp to see what can be done.
livings124: well, if miniupnp isn't working, i don't think libtransmission will work and we will not be modifying miniupnp
mmadia: I can confirm that at least 1.42 works with that ugly miniupnp hack.     it isn't my intention to have it remain, but simply to allow the porting effort to continue in the meantime.
livings124: 1. 1.42 is very old and doesn't have any relevance now 2. we are not the miniupnp developers, we won't touch that code, especially if the authors explicitly reject it
mmadia: 1. uploading the patch is more for record keeping and not to be committed to the  tag/1.42. 2) I understand that.   it is not my intention for that hack to remain in place.  it is a temporary measure to allow compilation to continue, as there are other issues that can be worked on. and trust me, if i had the ability to implement the needed code, it would've been done by now : )
mmadia: As for the CFLAGS changes, Haiku does have GCC 4.3.3, i simply haven't yet tried building trunk on it.

Here are some emails from prominent Haiku devs regarding what to do for trunk: Stephan Assmus is "stippi", Axel is "axeld", François Revol is "mmu_man", Ingo is "bonefish"

"Stephan Assmus" <> wrote:
> >  Charles Kerr, a developer for Transmission the bittorrent client
> > asked me about the progress of porting the current 1.51+ svn trunk
> > in
> > Haiku.
> >
> > Basically, v1.51+ has hard-coded support for IPv6.
> >
> > I'm not asking for IPv6 support, just some possible courses of
> > action
> > that can be suggested to Charles.
> I remember talking briefly about the subject with Ingo. Basically,
> IPv6 is not yet
> available by all providers. So the IPv6 code paths must be used
> optionally in
> Transmission. Otherwise the client would not work on most setups,
> right?
> So why is IPv6 being made a requirement at compile time?

That basically just means that the OS must provide the headers at
compile time; since the client cannot use IPv6 yet, we do not have to
provide actual functionality.
I don't think this would be much work, and we need those headers anyway
at some point (and eventually a few function stubs).

Bye,
  Axel.

-------------

François Revol replied to :
"Stephan Assmus" <> wrote:
> I remember talking briefly about the subject with Ingo. Basically,
> IPv6 is
>  not yet available by all providers. So the IPv6 code paths must be
> used
>  optionally in Transmission. Otherwise the client would not work on
> most
>  setups, right? So why is IPv6 being made a requirement at compile
> time?

Just #ifdef AF_INET6 ?
[edit: encapsulating all IPv6 code in such brackets]
François.
-----------

comment:14 follow-up: Changed 12 years ago by livings124

I'm not so sure how I feel about filling the code with a lot of #ifdef's to get it to work on an incomplete system.

comment:15 in reply to: ↑ 14 Changed 12 years ago by mmadia

Replying to livings124:

I'm not so sure how I feel about filling the code with a lot of #ifdef's to get it to work on an incomplete system.

What about splitting the functions into *_ip4() and *_ip6() implemented in separate files?

comment:16 Changed 12 years ago by livings124

I don't think it's a good idea to complicate our code base to support an incomplete operating system. Especially since your patch was rejected by the maintainers of miniupnp, whose code we rely on.

comment:17 Changed 12 years ago by charles

I mostly agree with livings124 on this. I don't think it's unreasonable for a network-intensive program to require ipv6 hooks in 2009.

One possibility, until Haiku actually gets ipv6 support, would be for you to maintain a patch that you could apply when building for Haiku. If there are other, non-ipv6 related issues that could be fixed in the main Transmission codebase, I'd be happy to take a look at those.

comment:18 Changed 12 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

Closing this ticket until Haiku is mature enough to support Transmission.

Note: See TracTickets for help on using tickets.