Re: Cross compile click packages

Hey Eddie,

if click-mkmindriver does not work with packages, building mixed tools 
is no longer necessary. Furthermore, i don't have the time to work on 
those cross compile issues, currently. I have to delay work on this for 
a few months. If i run into this problem again, i will provide further 
details or figure it out myself.

Sascha

On 01/09/12 19:22, Eddie Kohler wrote:
> Hi Sascha, sorry for my own late reply.
>
> Well, this code used to work; that is why Click separately checks for
> dynamic linking on the build & host compilers. To figure out this error
> I'd need to see the config.log.
>
> Unfortunately click-mkmindriver does not work with packages.
>
> Eddie
>
>
>
> On 12/3/11 6:36 PM, Sascha Alexander Jopen wrote:
>> Hey,
>>
>> sorry for this really late reply.
>>
>> Cross compiling click packages with your modifications of the build
>> system seems to work. I managed to compile and run several packages for
>> a mipsel architecture.
>>
>> However this will only work with --enable-tools=host.
>> --enable-tools=mixed leads to the following error during the configure
>> phase. I currently use different cxx libraries on the build and host
>> systems. But even when using the standard gcc cxx library, i couldn't
>> compile mixed tools. Both the build system and the target system do
>> support dynamic linking, so this might be a problem with mixed
>> build/host include and library directories.
>>
>> checking dlfcn.h usability... no
>> checking dlfcn.h presence... yes
>> configure: WARNING: dlfcn.h: present but cannot be compiled
>> configure: WARNING: dlfcn.h: check for missing prerequisite headers?
>> configure: WARNING: dlfcn.h: see the Autoconf documentation
>> configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled"
>> configure: WARNING: dlfcn.h: proceeding with the compiler's result
>> checking for dlfcn.h... no
>> checking for dlopen... no
>> checking for dlopen in -ldl... no
>> configure: error:
>> =========================================
>>
>> You have configured Click with '--enable-dynamic-linking', which requires
>> that both the build system and host system support dynamic linking.
>> Try running 'configure' with the '--disable-dynamic-linking' option.
>>
>> =========================================
>>
>>
>> The commands i used to configure and compile click with the cross
>> toolchain were the following. Do i have to provide other things for this
>> to work with mixed tools?
>>
>> AR=i486-openwrt-linux-uclibc-ar \
>> AS="i486-openwrt-linux-uclibc-gcc -c -O2 -pipe -march=i486
>> -funit-at-a-time -fhonour-copts" \
>> LD=i486-openwrt-linux-uclibc-ld \
>> NM=i486-openwrt-linux-uclibc-nm \
>> CC="i486-openwrt-linux-uclibc-gcc" \
>> GCC="i486-openwrt-linux-uclibc-gcc" \
>> CXX="i486-openwrt-linux-uclibc-g++" \
>> RANLIB=i486-openwrt-linux-uclibc-ranlib \
>> STRIP=i486-openwrt-linux-uclibc-strip \
>> OBJCOPY=i486-openwrt-linux-uclibc-objcopy \
>> OBJDUMP=i486-openwrt-linux-uclibc-objdump \
>> SIZE=i486-openwrt-linux-uclibc-size \
>> CPPFLAGS="-I/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/target-i386_uClibc-0.9.30.1/usr/include
>>
>> -I/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/target-i386_uClibc-0.9.30.1/include
>>
>> -I/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1/usr/include
>>
>> -I/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1/include
>>
>> -MD" \
>> CFLAGS="-O2 -pipe -march=i486 -funit-at-a-time -fhonour-copts -MD" \
>> CXXFLAGS="-O2 -pipe -march=i486 -funit-at-a-time -fhonour-copts
>> -nostdinc++ -MD
>> -I/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/target-i386_uClibc-0.9.30.1/usr/include/uClibc++"
>>
>> \
>> LDFLAGS="-L/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/target-i386_uClibc-0.9.30.1/usr/lib
>>
>> -L/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/target-i386_uClibc-0.9.30.1/lib
>>
>> -L/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1/usr/lib
>>
>> -L/home/buildbot/buildbot/data/OpenWRT/backfire/staging_dir/toolchain-i386_gcc-4.1.2_uClibc-0.9.30.1/lib
>>
>> -nodefaultlibs -luClibc++ -lm" \
>> ./configure --prefix=/usr --target=i486-openwrt-linux
>> --host=i486-openwrt-linux --build=i686-linux-gnu --enable-tools=mixed
>> --enable-userlevel --disable-linuxmodule
>>
>>
>> make tools elementmap.xml
>>
>>
>> I do not need the build system tools currently, but maybe the
>> mkmindriver tool could become interesting for me. Btw. will the
>> mkmindriver work with packages and compile only the required elements
>> into the package?
>>
>> Regards,
>> Sascha
>>
>>
>> On 11/09/11 18:10, Eddie Kohler wrote:
>>> Hi Sascha,
>>>
>>> I think I may have checked in something that will help you. You will
>>> need to update Click as well as your package's configure.ac and
>>> Makefile.in (the click-packages git has been updated to show you what
>>> is needed). Let me know.
>>>
>>> Eddie
>>>
>>>
>>> On Wed, Nov 9, 2011 at 9:27 AM, Sascha Alexander Jopen
>>> <[email protected]> wrote:
>>>> In my case it's the easier deployment. In particular, i use the OpenWRT
>>>> buildroot for cross compilation of click packages. I install the
>>>> complete click "base package" with DESTDIR into a staging directory for
>>>> further usage.
>>>>
>>>> So far i changed some definitions within the makefiles to use the click
>>>> build tools directly out of the source directory, because the installed
>>>> versions would be host binaries, not build system binaries. After
>>>> fixing
>>>> the include directories and data directories i could compile two
>>>> different packages for userlevel. Neither linuxmodules nor bsdmodule
>>>> will work with the attached patch.
>>>> Im pretty sure this patch is not complete. I'm really new to such
>>>> "complex" makefiles. For example, no dependency files (*.d) are
>>>> generated for my packges, though this worked before.
>>>>
>>>> Sascha
>>>>
>>>> On 11/09/11 15:07, Eddie Kohler wrote:
>>>>> In particular, it might be much easier to handle this:
>>>>>
>>>>> Click prefix => /usr/local/click
>>>>> Click temporary installation directory =>
>>>>> /usr/local/click-cross/usr/local/click
>>>>>
>>>>> than this:
>>>>>
>>>>> Click prefix => /usr/local/click
>>>>> Click temporary installation directory => /usr/local/click-cross
>>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>> On Wed, Nov 9, 2011 at 9:04 AM, Eddie Kohler<[email protected]> wrote:
>>>>>> Hi Sascha,
>>>>>>
>>>>>> Hmm.
>>>>>>
>>>>>> Can you tell me a bit more about your deployment situation?... Are
>>>>>> you
>>>>>> installing with a DESTDIR, or copying the whole tree somewhere else?
>>>>>> It is not immediately clear to me how this should be handled.
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 8, 2011 at 7:09 AM, Sascha Alexander Jopen
>>>>>> <[email protected]> wrote:
>>>>>>> Hey,
>>>>>>>
>>>>>>> does anybody cross compile click packages?
>>>>>>>
>>>>>>> If i cross compile click with the default prefix, but install it
>>>>>>> to a
>>>>>>> different location for further usage with click packages, the file
>>>>>>> config.mk in clickdatadir contains the original prefix. This is
>>>>>>> fine to
>>>>>>> define the directories for the final destination locations of the
>>>>>>> packaged to be cross compiled, but the package Makefiles use this
>>>>>>> information to find the installed click instance, too. One can
>>>>>>> configure
>>>>>>> a package with --with-click=PREFIX, but this doesn't help.
>>>>>>>
>>>>>>> I know that i can compile click with local elements instead of
>>>>>>> packages,
>>>>>>> but using packages is a cleaner way, i think.
>>>>>>>
>>>>>>> Are there any special configure flags or something similar i am
>>>>>>> missing,
>>>>>>> to get click packages cross compiled?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sascha
>>>>>>> _______________________________________________
>>>>>>> click mailing list
>>>>>>> [email protected]
>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>
>>>>>>
>>>>
>>>>
>>