e of a custom
prefix.
So with respect to the plugin and libssp questions, I would like to know
from the community if my changes make sense before I open bugs against GCC.
Best Regards,
-Jim Heck
Detailed build information and patches follow:
Problems building gcc statically as a crosscompiler for
heezy's release, and so might never be part of any official
release..
>Naturally, xapt will disappear with dpkg-cross and pdebuild-cross will
>be converted to simply make the toolchains available inside a pbuilder
>chroot - if that step turns out to still be necessary by the time
>Multi-Arch is at this stage.
Thanks in advance,
-Jim Heck
My project makes use of -dev packages. Specifically, we use these in
conjunction with a target NFS image that supports far more stuff than we
deploy in our actual flash image.
As such, we are currently not using Grip, but rather the full Debian mirror
packages, along with script based stripping o
Thanks for the detailed explanation Neil, and thank you for all the
excellent hard work you and the other Emdebian folks have put in on these
tools!
-Jim
On Sun, Nov 7, 2010 at 11:13 AM, Wookey wrote:
>
>
> Assuming 2.6.35 works with squeeze then it'll work with emdebian
> squeeze-vintage. I see squeeze uses 2.6.32 (which is syncronised with
> several other distros with relatively long support cycles IIRC). So
> far as I know 2.6.35 will be fine t
assume is a change in the output of 'apt-cache policy'. I found the
offending line that is no longer matching in
/usr/share/perl5/Cache/Apt/Config.pm and fixed it. Below are the results of
my debugging process.
Best Regards,
-Jim Heck
** Failing output of apt-cross
jh...@sque
xapt is already in Squeeze as part of the pdebuild-cross package:
$ sudo apt-get install pdebuild-cross
$ man xapt
$ /usr/share/pdebuild-cross/xapt --help
The change is to enhance xapt and put it into /usr/bin but the enhanced
version will still only support installation, not just downloading.
able to perform this function I could get by just downloading the
needed debs manually from the appropriate repository, but it would be
nice if the Squeeze release has some tool that allows me to do this by
harnessing the apt infrastructure.
Best Regards,
-Jim Heck
--
To UNSUBSCRIBE,
> Dnia poniedziałek, 13 września 2010 o 22:11:24 Jim Heck napisał(a):
>
> > I am building the gcc-4.4 unmodified from unstable with the following
> > command line
>
> > PF=/opt/ilomtools/crosscompiler/gcc-4.4__100910/arm
> > DEB_BUILD_OPTIONS=static DEB_CRO
Hector,
Thanks for the response.
I will try your suggestion. Could you briefly explain what the implications
are of building without DEB_CROSS_NO_BIARCH=yes? Will it just simply build
the additional 64 bit libraries and not change any other aspect of the
toolchain? I assume those 64 bit libs n
In case it mattered (which I highly doubt), I'm using the experimental
version of binutils (2.20.51.20100908-1).
Also, just wondering, is it likely that this experimental version will be
adopted before squeeze is finalized? I ask, since that is the version I had
my prefix and static patches incor
Several of my patches for cross building gcc-4.4 with prefix and statically
have been recently accepted, so I thought it would be a good time to try to
build the unstable version and see if recent changes have affected my
ability to build a toolchain. I ran into the following dh_link error, where
ase-passwd bash bc binutils busybox coreutils
>
> You don't need to specify all of these - anything that is Priority:
> required will be added unless you specify omitrequired in the config.
> (Also in the manpage.)
>
Yes, thanks, I already knew that, but it's easier to keep
either includes
or does not include various packages without ending up with the warnings or
the duplication of sources.list entries? I have avoided the multiple
entries by listing only one of the stanzas in the aptsources= line, but the
warning caught my eye.
Thank you very much for your
Or am I doing something
wrong?
Thanks,
-Jim Heck
it as the suite I get a
different 404 error. The multistrap man page doesn't really go into this
kind of detail in its example. Could you provide an example that pulls from
a component?
Thank you very much,
-Jim Heck
For example, when I tried it as the source line like this:
...
[Dev]
other -dev
packages. I'm not sure what I'm doing wrong.
Thanks,
-Jim Heck
Here are more details:
For example, I'm trying to pull in libc6-dev, which depends on libc6. I get
the following error
The following packages have unmet dependencies:
libc6-dev: Depends: libc6 (= 2.11
I'm not sure if this is related, but I just found a problem that has
crept in as of gcc-4.4-4.4.4-7 that seems related to the base package.
I just now noticed that for my build of the armel compiler, that from
gcc-4.4-4.4.4-6 to gcc-4.4-4.4.4-7, the package
gcc-4.4-arm-linux-gnueabi-base packa
Out of curiosity, are you just interested on armel architecture? Other
architectures need more love at the moment.
Hector,
Besides armel, I also have an interest in the SH architecture, but I'm
not sure how deep that will run. I have evaluated it for a potential
use, but have still no
I have submitted two wishlist bugs with patches that may be of embedded
interest.
binutils
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590101
gcc-4.4
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590102
These are to allow the building of static toolchains by passing an
environment var
On 7/21/2010 6:15 PM, Hector Oron wrote:
Hi Jim,
This bug is introduced by latest changes done by Linaro folks.
Previously, you were able to build regular tools, only by setting
WITH_SYSROOT=$some_path enviroment variable before the build, you
could build a sysroot binutils.
Yes, as I jus
On 7/21/2010 5:32 PM, Loïc Minier wrote:
On Wed, Jul 21, 2010, Jim Heck wrote:
I have run into another problem that seems related to the recent
changes to binutils to set sysroot to /$(PF)/$(TARGET) for cross
builds. I don't fully understand why, but my build of
gcc-4.4_4.4.4.6 wi
d the compiler
normally (without my added prefix PF=blah).
Thanks,
-Jim Heck
Here is some more information:
The rules makefile of binutils changed in 2.20.51.20100710-1, such that
the stanza
#-
# sysroot options
ifdef WITH_SY
gcc-4.4.4/arm TARGET=armel
dpkg-buildpackage -us -uc -rfakeroot
I'd be happy for this change to be peer reviewed and possibly adopted in
the upstream binutils package. Any pointers as to how I can help
facilitate this are most welcome.
Thanks,
-Jim Heck
The following diff is of th
(I've cut the Cc's back to just the list)
Loïc,
Thank you for the bug reporting tips. I knew there was a specific diff
format that was favored, but I couldn't remember what it was. I will
use -u in the future and check out your DIFF alias also.
To answer your question on my "use case" for
uot;usr" for gcc releases
< ifeq ($(PKGSOURCE),gcc-snapshot)
---
> # It's "usr" for gcc releases, so use this if not explicitly set
> ifneq ($(PF),)
> else ifeq ($(PKGSOURCE),gcc-snapshot)
I also have a diff file for binutils, for the prefix modification based
on
3.2+dfsg-1_all.deb
libstdc++6-armel-cross_4.4.4-5_all.deb libmpfr1ldbl-armel-cross_2.4.2-3_all.deb
I should also note that this technique is one that I have just recently
been developing and am still testing.
-Jim Heck
--
To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
wit
The following are patch files that I apply to the binutils and gcc-4.4
in order to get them to build for use at an alternate prefix. I post
these for general interest and discussion. I use these modifications to
create tools that can be installed under /opt/.. instead of /usr/.. in
support of
t the diffs here and would appreciate
feedback on how best to submit them upstream.
Thanks,
-Jim Heck
--
To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c2a3e4b.7010...@oracle.com
ile a wishlist bug against binutils and gcc
Debian packages with the patches?
Thanks,
-Jim Heck
--
To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c2a45a7.6050...@gmail.com
e autobuilder network to build those packages. Does
autobuilder only support native building, or is there a way to setup to
use an Emdebian cross compiler environment to build packages?
Thanks in advance for any help,
-Jim Heck
the Linux kernel on boot (the technique
employed varies from architecture to architecture).
-Jim Heck
--
To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debi
> > their script, or things would be broken.
>
>
> It would only be broken for the next run of root filesystem builds. In
> most cases, such builds take packages from Debian stable so the
> packages don't change that much.
>
>
They change generally mostly as a new release becomes the new stable.
-Jim Heck
n my
experience, this usually boils down to a few repeatable steps such as
installing links in the initscripts, creating a few softlinks, etc.
Also a general comment. I have to commend you (Neil) and the rest of
the Emdebian folks, this project is really turning into something very
neat! Gre
Longtime lurker here.
Overall I think this is an excellent idea.
I can validate that there is use for this approach, since it parallels
in many ways the roll it yourself method for maintaining a small
embedded "baked" distribution currently used by a commercial product I
work on. Once the sy
Neil Williams wrote:
What if I could add a line '#include apt.conf-unstable.local' that
could include a separate file? (Along the lines of how bind handles
named.conf.local?) It is probably the better solution, overall.
You could then leave apt-cross to manage
~/.dpkg-cross/apt.conf-unstable a
Neil Williams wrote:
On Thu, 01 Feb 2007 19:33:02 -0500
Jim Heck <[EMAIL PROTECTED]> wrote:
I first instrument the code with some prints to show that the
conditional inside the find_latest_gcc never gets entered. By my
analysis, this is due to the fact that in the regexp, the gr
It may simply be necessary to *not* use 'emsetup' if the toolchain is
unsupported - I'm not sure if Jim's proposed method will work out but
I'll take a look at patches that have a neutral effect on the supported
usage.
OK Thanks. I'm not trying to create more work for you vis a vis bugs
re
t is what they have
installed. I didn't, however, code any of that up yet as a proposed
patch. Does anybody think that would be a good idea?
-Jim Heck
androcross: /usr/share/perl5/Emdebian
$ diff Tools.pm Tools.pm.orig
130,133d129
<
< # JAH HACK
< return &qu
Neil Williams wrote:
There's an outline of a pbuilder create wrapper in SVN
(tools/em_make/empdebuild) - once a few more packages are built, we
should have a usable chroot environment using the emdebian target
repository.
Wow, I'm really impressed with how far and fast Emdebian seems to be
n and that works fine.
In general how does emdebian plan to get around invocation of native
binaries as part of the compilation process? Is QEMU the right
approach? Will there be emdebian build patches for packages such as
this that will newter the testing configure does?
Thanks,
-Jim Heck
PS
e from gcc-4.0. Was
that because there is a specific problem with the one from gcc-3.4?
I just wanted you to know I have a workaround so you don't waste any
time on it.
Thanks,
-Jim
Jim Heck - Sun Microsystems wrote:
Hector,
Thanks for all your help so far.
I found one other thing
Hector,
Thanks for all your help so far.
I found one other thing that may be of interest to you concerning the
gcc-3.4 libstdc++6-powerpc-cross package. There is a typo in the
generated dependencies of the package (see below, powerpc-cross is
duplicated). I tried to analyze and my best gues
updated once in a blue moon.
Point 5 is a minor one and most likely outside the scope of Emdebian,
but still an issue that many developers will struggle with on embedded
projects (I know I am :-).
Thanks for reading,
-Jim Heck
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
this manner, and for this I think Emdebian has
great promise. I will try to clarify somewhat what I am talking about.
Neil Williams wrote:
On 08/11/06 21:06:28, Jim Heck - Sun Microsystems wrote:
2. I'm confused by "local source control" - is this a private VCS
(CVS/SVN/arch etc
NX is the home of u-boot, the whole site serves as a
nice primer on embedded development. At the very least you'll learn
some interesting stuff. I believe u-boot has a port to work on coldfire
boards, too.
Good luck,
-Jim Heck
kitts wrote:
Hi All,
I am new to this list and am int
ough I can't think of a nice clean way to do this without
hacking out the build dependency on the linux-kernel-headers package,
which doesn't exist for 2.4 kernel headers).
If you've read this far thanks!
Any help or ideas, double thanks!
-Jim Heck
Listing installed files not in
owerpc. Is this useful in some way?)
Thanks,
-Jim Heck
Neil Williams wrote:
http://buildd.emdebian.org/repos/tools/emchain/
emchain implements the EmdebianSlind toolchain build process for
the latest versions of gcc, binutils and libc. To build toolchains
for older compilers, see the Emdebian
ironment variable in the busybox makefiles). I don't have any
significant environment variables set that I know of.
Any help or insight appreciated.
Thanks,
-Jim Heck
androcross:/usr/src/cross-packages/busybox-1.1.3# dpkg-buildpackage
-apowerpc -us -uc -rfakeroot -b 2>&1 | tee ../busybox.b
I've opened a gcc-4.1 bug against it.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391445
-Jim
Hector Oron wrote:
Hello Jim,
If it helps I ran into same error, and Wartan also. So, it might need
to be fixed some how.
Regards,
Hector
2006/10/5, Jim Heck < [EMAIL PROTECTED]
x27;t need it. Any additional help you could
give to get me further along would be greatly appreciated.
Thanks for the help,
-Jim Heck
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-e 's/@CXX@/6/g' \
-e 's/@GCJ@/7/g' \
-e 's/@LC@/1/g' \
-e 's/@FFI@/4/g' \
-e 's/@GFDL@//g' \
$f > $f2; \
touch -r $f $f2; \
done
CANNOT FIND debian/*FFI*
make[1]: Leaving directory `/usr/
52 matches
Mail list logo
