cross compilation problems

[John (J5) Palmieri]

Hi Dave,

Could you possibly supply your workarounds as patches to the
configure.in and Makefile.am files in CVS? You sent patches on the
generated files.  I am pretty sure the auto tools can handle cross
compilation issues.  In fact there should be a way to just use DESTDIR
to deal with alternate buildroots so all the files are installed in an
alternate root directory.  For instance installing to /etc with a
DESTDIR of /home/me/build would install to /home/me/build/etc but
everything would still point to /etc so when it installed on the target
to the correct directories all the links work.  We use this trick to
package up RPMS.

In any case it would be nice to get things to work for you without you
having to patch every time.
  
On Tue, 2005-10-11 at 18:58 -0400, Dave Plauger wrote:
> 
> John (J5) Palmieri wrote On 10/11/05 16:38,:
> > On Sun, 2005-10-09 at 11:32 -0400, Dave Plauger wrote:
> > 
> > 
> >>Here are some of my thoughts:
> >>
> >>1) I need only a system daemon in my embedded system
> > 
> > 
> > System and session daemons are just a matter of what config file they
> > read.
> 
> Well, there is a built in assumption that a system daemon shouldnt use
> abstract sockets. And, the example system.conf does not provide for
> service dir. I realize that "system" and "session" are concepts that
> dont affect the implementation very much. But, there are assumptions
> about each mode that do creep in. Please dont ever go down the path of
> enforcing in the implementation things like "system daemons cant do
> that", "session daemons cant do this".
> 
> > 
> > 
> >>2) abstract sockets are OK for this case
> >>3) would like to have placement option in the config for system.conf
> >>    e.g.: put system.conf in /etc, put pid file in /var
> > 
> > 
> > doesn't --sysconfdir and --localstatedir handle this at configure time
> > or am I not clear on what you are suggesting?
> 
> This is what I mean by "cross compilation problems". In my case --host
> is not the same as --build. The makefile should not use target file
> paths on the build server. It should not tack on "dbus-1", either.
> However, I do need dbus lib and include files on the build server for
> building dbus apps.
> 
> If I add this desired path in the target system:
> 	--sysconfdir=/etc/dbus
> 
> The build fails:
> 
> ...
> /usr/bin/install -c dbus-daemon
> /workspace/djp/ws/external/dbus/bin/dbus-daemon
> test -z "/etc/dbus/dbus-1" || mkdir -p -- "/etc/dbus/dbus-1"
> make[3]: Leaving directory `/workspace/djp/ws/external/dbus/dbus-0.50/bus'
> make[2]: Leaving directory `/workspace/djp/ws/external/dbus/dbus-0.50/bus'
> make[1]: Leaving directory `/workspace/djp/ws/external/dbus/dbus-0.50'
> mkdir: cannot create directory `/etc/dbus': Permission denied
> make[3]: *** [install-configDATA] Error 1
> make[2]: *** [install-am] Error 2
> make[1]: *** [install-recursive] Error 1
> make: *** [install] Error 2
> 
> I'm reporting that cross compilation mode is very close to working, but
> can use some attention. I had supplied my works-arounds, hoping to
> illustrate.
> 
> > 
> > 
> >>4) like to use auto start feature with system daemon
> >>    It's easier to let dbus-daemon start up services on demand (system init)
> >>    If a service crashes or exits, it can come back (robustness)
> > 
> > 
> > This requires either an external activation daemon that talks with the
> > system bug or you can simply run the bus as the root user and add a
> > service directory directive in the system.conf file.  There may be some
> > security concerns when running the bus as root.
> > 
> > 
> >>5) We use the C binding only, dont have much space in flash/ram
> > 
> > 
> > You can disable all bindings using --disable-<binding> switches in the
> > configure stage (use ./configure --help to see a listing of switches).
> >  
> 
> Sure, did all that. I am up and running. I was just trying to report
> some bugs in configure. And I guess I confused things by telling you my
> assumptions. I hoped to highlight that my application of DBus is a
> little different. And, I'd like you guys to carefully consider what
> assumptions you place in configure and makefiles.
> 
> Thanks.
> 
> 
--