Hi Qiang,
Thanks for looking into this. I really do appreciate it.
> GBS use totally Tizen chroot env to build package, so it will not use
host env and library.
That may be the intent, but it doesn't seem to be true on my system.
Otherwise, my adding those symbolic links would not have altered anything.**
As an additional test, today I altered the symbolic links in the top level
of my host machine to the following:
/usr/lib/gcc/i586-tizen-linux ->
/usr/lib/gcc/x86_64-linux-gnu
/usr/i586-tizen-linux ->
/home/smaurer/GBS-ROOT-git3/local/BUILD-ROOTS/scratch.i586.0/usr/i586-tizen-linux
(note: the latter path goes to the local GBS-ROOT alternative, of all the
different configurations I've been trying to get this to work.)
When I did this (and also added the missing "intl" directory into
.../scratch.i586.0/home/abuild/rpmbuild/BUILD/gettext-0.18.1.1) the
following command finished without error:
gbs build -A i586 --incremental
platform/upstream/gettext
So I think I can state categorically that, at least for my system, gbs has
a dependency on the external build machine/
> For your case about build-initvm.spec, actually, this package also has
not been build in OBS and does not exist in released repo:****
>
http://download.tizen.org/releases/daily/tizen/ivi/latest/repos/ivi/ia32/packages/
****
**Thanks. That's good to know. We got instructions last week about using
some specific manifests
(tizen_20130829.9-ivi-release-mbr-i586.manifest.xml) and the repo "
http://download.tizen.org/releases/daily/tizen/ivi/tizen_20130913.12/";.
However after trying it out, it barely compiled any packages at all. There
were huge and repeated conflicts between the Tizen gcc-4.8 package and the
Tizen gcc-4.7 package, on a completely virgin checkout (compiled with
gcc4.8 installed in Ubuntu).**
Due to this, I went back to the following (again on a virgin checkout):
repo init -u ssh://
[email protected]/scm/manifest -m ivi.xml; repo sync
And ran this command:
gbs build -A i586 --threads 2 --clean-once
--exclude=texinfo,systemd,build
...on repo url=${work_dir}/pre-built/toolchain-x86/
------------------------------------
...for which I got the errors I mentioned above, about 100 packages further
on. I then got even further by putting in the symbolic link hacks.
You will note that I simply excluded the "build' package (which used
build-initvm.spec), because the spec file told me to change it to looks
like what I already have, so I could not fix it any further.
Now today, I went ahead and tried to build with the above symbolic links in
place, and doing so let me get further in building than I ever have before. I'm
now more than a third of the way through. Almost to the point where I could
begin to actually contribute to Tizen IVI, maybe.
> Which code base(snapsho) are you using? The latest one is
http://download.tizen.org/releases/daily/tizen/ivi/tizen_20130917.3****
> Are you using tizen.org git manifest or manifest in
http://download.tizen.org/releases/daily/tizen/ivi/tizen_20130917.3/builddata/manifest/
?
**I did not, but I intend to see what happens when I do, so in a fresh
directory I am doing the following:**
repo init -u tizen:/scm/manifest -m
tizen_20130917.3_ia32.xml
repo sync -m tizen_20130917.3_ia32.xml
Putting in a .gbs.conf file that points to
the repository you mentioned.
gbs build -A i586 --threads 1 --clean-once
--exclude=texinfo,systemd,build
If this fails, I'll go and change the link in /usr/i586-tizen-linux to the
new GBS-ROOT location.
This is going to take a while, so I'll likely have to tell you the results
tomorrow.
Thanks, ~ Steve
On 17 September 2013 23:46, Zhang, Qiang Z <[email protected]> wrote:
> GBS use totally Tizen chroot env to build package, so it will not use
> host env and library.****
>
> ** **
>
> For your case about build-initvm.spec, actually, this package also has not
> been build in OBS and does not exist in released repo:****
>
>
> http://download.tizen.org/releases/daily/tizen/ivi/latest/repos/ivi/ia32/packages/
> ****
>
> ** **
>
> That means build-initvm.spec has not been used for finally tizen image,
> the real reason for this package is that it missing a dependency, you can
> fix like this:****
>
> ** **
>
> /upstream/build$ git diff****
>
> diff --git a/packaging/build-initvm.spec b/packaging/build-initvm.spec****
>
> index cef4a23..e259ef7 100644****
>
> --- a/packaging/build-initvm.spec****
>
> +++ b/packaging/build-initvm.spec****
>
> @@ -28,9 +28,7 @@ AutoReqProv: off****
>
> Requires: build****
>
> BuildRequires: gcc****
>
> BuildRequires: glibc-devel****
>
> -%if 0%{?suse_version} > 1200****
>
> BuildRequires: glibc-devel-static****
>
> -%endif****
>
> ****
>
> %description****
>
> This package provides a script for building RPMs for SUSE Linux in a****
>
> ** **
>
> Which code base(snapsho) are you using? The latest one is
> http://download.tizen.org/releases/daily/tizen/ivi/tizen_20130917.3****
>
> ** **
>
> Are you using tizen.org git manifest or manifest in
> http://download.tizen.org/releases/daily/tizen/ivi/tizen_20130917.3/builddata/manifest/?
> ****
>
> ** **
>
> Thanks****
>
> Qiang****
>
> ** **
>
> ** **
>
> *From:* [email protected] [mailto:[email protected]] *On
> Behalf Of *Maurer, Steven
> *Sent:* Wednesday, September 18, 2013 5:52 AM
> *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]****
>
> ** **
>
--
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]
-------------------
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070
This e-mail and any attachments contain confidential information for a
specific individual and purpose. The information is private and privileged
and intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient, please e-mail us immediately. We
apologise for any inconvenience caused but you are hereby notified that any
disclosure, copying or distribution or the taking of any action in reliance
on the information contained herein is strictly prohibited.
This e-mail does not constitute an order for goods or services unless
accompanied by an official purchase order.
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
