| Summary: | SDK libtool wrapper when compiling for native host is broken | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jacob Kroon <jacob.kroon> |
| Component: | devtools / tool chain | Assignee: | Jacob Kroon <jacob.kroon> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | jacob.kroon, liezhi.yang, meta.mr.watcher, meta.watcher, randy.macleod |
| Version: | unspecified | ||
| Target Milestone: | 1.8 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Jacob Kroon
2015-01-06 14:23:31 UTC
I thought passing --host=x86_64-oesdk-linux would be good enough, but it seems that when I switch to using shared libraries instead of static libraries in my project, when I build the project natively for my host, the resulting libtool-wrapped binaries won't execute due to not finding the shared libraries I build. Looking at the libtool OE patches I see there is a "fixinstall.patch". If this is the culprit, would it be possible to remove it for the nativesdk version of libtool ? I'm a little confused as to why no one else seems to be complaining about this. Am I doing something crazy and unusual here ? I want to be able to build my project both for the OE SDK target system, and my host system, so I want to run autoreconf _once_ in the srcdir, using the SDK's version of autotools/libtool/etc, and have different VPATH builds for target and host going at the same time. Removing "fixinstall.patch" in nativesdk-libtool does indeed let me execute host binaries that links with libtool shared libraries. Would it be an acceptable solution to remove "fixinstall.patch" from nativesdk-libtool recipe only ? (In reply to comment #2) > I'm a little confused as to why no one else seems to be complaining about > this. Am I doing something crazy and unusual here ? > > I want to be able to build my project both for the OE SDK target system, and > my host system, so I want to run autoreconf _once_ in the srcdir, using the > SDK's version of autotools/libtool/etc, and have different VPATH builds for > target and host going at the same time. Sorry for the late response. IIRC, we need use configure $CONFIGURE_OPTS (or something similar) on the SDK. I don't think that we should remove fixinstall.patch for SDK, the SDK is used for building pkgs which is running on the target, not running on the build host. (In reply to comment #4) > Sorry for the late response. IIRC, we need use configure $CONFIGURE_OPTS (or > something similar) on the SDK. I don't think that we should remove > fixinstall.patch for SDK, the SDK is used for building pkgs which is running > on the target, not running on the build host. What I have done now is to ship and patch libtool.m4, so that it is possible to override "LIBTOOL" during ./configure. This way I can use my host version of libtool for the native build, and the SDK version for the target build, everything configured from the exact same source directory. But I consider this a workaround, and having this sorted out in the SDK libtool would, at least to me, seem like the best longterm solution. (In reply to comment #5) > (In reply to comment #4) > > Sorry for the late response. IIRC, we need use configure $CONFIGURE_OPTS (or > > something similar) on the SDK. I don't think that we should remove > > fixinstall.patch for SDK, the SDK is used for building pkgs which is running > > on the target, not running on the build host. > > What I have done now is to ship and patch libtool.m4, so that it is possible > to override "LIBTOOL" during ./configure. This way I can use my host version > of libtool for the native build, and the SDK version for the target build, > everything configured from the exact same source directory. But I consider > this a workaround, and having this sorted out in the SDK libtool would, at > least to me, seem like the best longterm solution. If I understand correctly, you want to build nativesdk tools on SDK ? This is not supported AFAIK. You need re-create the SDK if you need more nativesdk tools. Jacob, This does seem like a bug in the SDK to me. It would help Robert and me to work though this defect, if you could reduce your project to the minimum required to reproduce the problem you are seeing. You could push such a minimum project to github or attach a tarball here. Please include as much detail as you can since we're not familiar with your workflow. Thanks. Following this example:L http://www.yoctoproject.org/docs/1.8/adt-manual/adt-manual.html#autotools-based-projects Note the need to invoke configure like this: ./configure ${CONFIGURE_FLAGS} works on current master and I can also build for the local host like this: CC=gcc ./configure && make or even let configure find the compiler like this: CC= ./configure && make Closing defect. Feel free to re-open with a detailed reproducer. |