BTW, Steve tells me that when he added the path in question to the root of his host system this immediate error went away and he got another (later in the build...)
So it sounds like this path on the host is being used, *somehow*! [?] Paul Paul Hanchett ------------------- Infotainment Engineer MSX on behalf of Jaguar Land Rover One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: [email protected] ------------------- Business Details: Jaguar Land Rover Limited Registered Office: Abbey Road, Whitley, Coventry CV3 4LF Registered in England No: 1672070 On Tue, Sep 17, 2013 at 8:09 PM, Hanchett, Paul < [email protected]> wrote: > I'm trying to look at this with new eyes: > > /usr/lib/gcc/i586-tizen-linux/4.8/../../../../i586-tizen-linux/bin/ld: > cannot find -lc > > > On my workstation I can > find > /home/paulha/GBS-ROOT/local/BUILD-ROOTS/scratch.i586.0/usr/i586-tizen-linux/bin/ld > (the linker). The path that's called out in the error message is kind of > funky... > > Looking at the properties for the file ld, it says it's a symbolic link > but that the link is broken. Surely, that's not right? > > Beyond that, the error message "ld: cannot find -lc" would typically mean > that the linker can't find library "libc" of some version... Right? Could > we be missing a library? > > Paul > > > > Paul Hanchett > > ------------------- > Infotainment Engineer > MSX on behalf of Jaguar Land Rover > One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, > Oregon, 97204 > > Email: [email protected] > ------------------- > > Business Details: > Jaguar Land Rover Limited > Registered Office: Abbey Road, Whitley, Coventry CV3 4LF > Registered in England No: 1672070 > > > On Tue, Sep 17, 2013 at 3:05 PM, VanCutsem, Geoffroy < > [email protected]> wrote: > >> Isn’t that absolute path an absolute path valid within the chroot >> environment (instead of an absolute path on your host)?**** >> >> ** ** >> >> I’m sure the **real** experts may scream at my oversimplification but my >> understanding is that GBS/OBS do not cross-compile, instead they set-up a >> chroot (for x86) or a QEMU VM (emulating the processor arch they target) >> and install the build tools in that environment (as opposed to pointing at >> a specific path where the cross-compiler is located)… so they never really >> reach out to use the tools from the host machine.**** >> >> ** ** >> >> Geoffroy**** >> >> ** ** >> >> *From:* [email protected] [mailto:[email protected]] >> *On Behalf Of *Clark, Joel >> *Sent:* Tuesday, September 17, 2013 11:59 PM >> *To:* Maurer, Steven; [email protected] >> *Subject:* RE: Major reason for inability to build Tizen sources found... >> **** >> >> ** ** >> >> Is there any chance this depends on an environment variable to prepend a >> path such as …/home/joel/tizen-devel-tools/ (or something similar) to the >> absolute path you found?**** >> >> ** ** >> >> Regards**** >> >> Joel**** >> >> ** ** >> >> ** ** >> >> *From:* [email protected] >> [mailto:[email protected]<[email protected]>] >> *On Behalf Of *Maurer, Steven >> *Sent:* Tuesday, September 17, 2013 2:52 PM >> *To:* [email protected] >> *Subject:* Major reason for inability to build Tizen sources found...**** >> >> ** ** >> >> Hi people,**** >> >> ** ** >> >> I've just come across a reason why I've been unable to build Tizen IVI in >> a vanilla environment: there are absolute paths to tool chains and >> dependencies on specific internal libraries of the cross-platform host.** >> ** >> >> ** ** >> >> When I attempt to "gbs build -A i586 platform/upstream/build" in the root >> git directory, the following error is left in the failure log: >> .../logs/fail/build-initvm-20120927-0/log.**** >> >> ** ** >> >> >> /usr/lib/gcc/i586-tizen-linux/4.8/../../../../i586-tizen-linux/bin/ld: >> cannot find -lc**** >> >> ** ** >> >> This error shows that the build depends on an absolute path in the host >> machine. A directory /usr/lib/gcc/i586-tizen-linux/4.8 must exist, a >> /usr/i586-tizen-linux/bin/ld must exist, and there is an implicit >> dependency on the host's library files. This also happens with >> platform/upstream/gettext package. I strongly suspect that many more >> packages have this dependency as well, but cannot test it because nothing >> else builds past those two packages.**** >> >> ** ** >> >> To test further, I went ahead and made a number of symbolic links to >> point these absolute paths to my local host's default toolchain, and tried >> to rebuild. This immediately ran into a link error because my host >> environment is Ubuntu 64-bit, and this naturally didn't link with the >> 32-bit Tizen executables.**** >> >> ** ** >> >> A total of 239 of 850 packages do build correctly before getting to these >> dependencies, but these are all just vanilla Linux packages. All the >> Tizen-specific libraries and applications needed for Tizen-specific >> development (for example developing a vehicle specific plugin >> for automotive-message-broker) do not build. I run into an onslaught of >> "nothing provides <package>" errors. I am unsure about whether this is >> caused by the toolchain dependency.**** >> >> ** ** >> >> In the short term, I would like some help from the people who actually >> *can* build further than this. Where are people getting this >> i586-tizen-linux toolchain from? It does not appear to be documented >> anywhere accessible by google. Until I can get this, I cannot do any sort >> of Tizen development. It is impossible, as has been suggested, to simply >> build packages to work on top of Tizen. To do such development you still >> need basic Tizen libraries and header files, and the packages that provide >> those don't build.**** >> >> ** ** >> >> In the long term, let me also state my concerns as to why this can't just >> be ignored. Since it appears that Tizen images have library code from the >> development environment baked into them, everyone's Tizen image is going to >> differ, even if built from identical sources, and this could lead to >> consistency issues. There is also a GPL issue, as incorporating non-public >> libraries and irreproducible build environments that make seemingly public >> code non-buildable is something it specifically prohibits (not everybody is >> so persnickety, but automotive manufacturers are very cognizant of legal >> liabilities).**** >> >> ** ** >> >> -- **** >> >> Kind Regards >> >> Steven Maurer >> ------------------- >> Infotainment Engineer >> MSX on behalf of Jaguar Land Rover >> One World Trade Center, 121 Southwest Salmon Street, 11th Floor, >> Portland, Oregon, 97204 >> >> Email: [email protected]**** >> >> ** ** >> >> Intel Corporation NV/SA >> Kings Square, Veldkant 31 >> 2550 Kontich >> RPM (Bruxelles) 0415.497.718. >> Citibank, Brussels, account 570/1031255/09 >> >> This e-mail and any attachments may contain confidential material for the >> sole use of the intended recipient(s). Any review or distribution by others >> is strictly prohibited. If you are not the intended recipient, please >> contact the sender and delete all copies. >> >> _______________________________________________ >> IVI mailing list >> [email protected] >> https://lists.tizen.org/listinfo/ivi >> >> >
<<32B.gif>>
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
