similar to: gsm codec compile

I am trying to cross compile openssh for arm5b-jungo-gnu-gcc,, and also using openssl and zlib from same compiler arm5b-jungo-gnu-gcc but i am getting following error,,, /usr/local/openrg/armv5b-jungo-linux-gnu/bin/armv5b-jungo-linux-gnu-ld: warning: cannot find entry symbol _start; defaulting to 0000b9c8 /usr/local/openrg/armv5b-jungo-linux-gnu/bin/../armv5b-jungo-linux-gnu/lib/libcrypto.so:

I am very new to linux and openSSH ,, i am trying to compile openssh for jungo openrg IXP45. but while configuring i am getting following error,, hecking for libgen.h... yes checking for getspnam... yes checking for library containing basename... none required checking for deflate in -lz... no configure: error: *** zlib missing - please install first or check config.log *** if anybody will me

Hi I'm trying to build an Asterisk packages for a C3 system (256MB memory, cpuinfo below). /proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping : 8 cpu MHz : 1000.736 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu

On Thursday 04 October 2007 04:27:47 you wrote: > Sir, you need to provide more information. What kind of errors? What > is not working? What exactly are you trying to do? What compiler are > you using? H IV0, we are using a lot of different cross-compiler (mainly based on GCC 3.4.x) When I tried to cross-compile FLAC for non-i386 platforms (such as ARM), I use use

Hi all, I'm trying to compile asterisk on the mainframe (s390 / s390x) and I am running into issues. I was wondering if somebody could give a hand? I'm thinking that I should be able to do this. I have noticed that Debian even has binary RPM's out for Asterisk now. I'm trying to do this on SuSE SLES8 (with the 2.4 kernel). What I see is, an issue that arch=s390 isn't

I see that lots of improvements have happened in cross configure support compared to version 3.8p1 but a couple of problems remain 1) The check that openpty does not reacquire controlling terminal (line 1326 in configure.ac) does not have a default value - I ran the test on my target and checked it was OK but I'm not sure what is the best default for others. 2) The etc_default_login

I have built Asterisk on SuSe Linux 7.3 on an Ultra 2 Sparc WorkStation. I am listing the modification I had to do for the benefit of anybody else who wants to use Asterisk This workstation is equipped with one 400 MHz RISC UltraSparc II CPU, 256 MB RAM, Two 9 GB 10,000 RPM UltraSCSI Disks. I have a gatekeeper running on this machine, I had to do the following modification to build * on Sparc:

I've cross-compiled flac for the armv4l processor (rio receiver), and i'm trying to start up a decode thread : #include <FLAC/stream_decoder.h> .... FLAC__StreamDecoder *flac = NULL; flac = FLAC__stream_decoder_new(); if (flac == NULL) { printf("[DECODE] Unable to initalize flac object\n");

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

Add the possibility to choose which architecture use to build the wanted image (--arch). Since this implies that running commands on the guest is usually not possible when the architecture is different than the host one, another new option (--allow-foreign-arch-ops) allows to run commands nevertheless. The caching scheme is adapted to account for the architecture (with --print-cache showing the

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to

>> However, because the DefaultTargetTriple is armv6l-unknown-linux-gnueabihf, >> and llvm didn’t know about v6l, it would fail to match and canonicalize to armv6. >> I added the notion of v6l to llvm to address this. > > ARMv6l was definitely there once. I'm not sure what happened. > > I'm copying the ARM folks that did most of the recent changes in hope

Hi all. I’ve been working with Swift on ARMv6 and v7. While working with ARMv6 on linux, I noticed that my arm architecture canonicalization code didn’t produce the expected result. The code that I had been using (within Swift’s Driver.cpp the following: static llvm::Triple computeTargetTriple(StringRef DefaultTargetTriple) { llvm::Triple triple = llvm::Triple(DefaultTargetTriple); //

Oops, I neglected to reply-all…. The current stable branch at github still has it: https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106> Should I get the head of the non-swift repository and generate a new diff? Also, I suspect that it’s not a good idea

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

Hi all, Thank you so much for this discussion. It has been very helpful and educational. I think that I understand the perspectives of both Tim and Renato. Let me briefly summarize them to ensure that I correctly understand: Renato’s perspective is that the triple means whatever the author says it does, and that may or not be meaningful. :) In the case of armv7l (for example) it has a clear

Taking the suggestions of the group under consideration, I’ve generated a new diff. The thing to note is that armv6l is now treated identically to armv6hl. I’ve also added a unit test. This seems to me to be the least invasive method, and holds to existing conventions as closely as possible. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name:

Cool, i'll help out a bit with the windows port, i will start right away with a new project on asteriskguru making nightly executable builds and installers - will post the links in -users when i'm done. Well done luigi, this will make it a lot easier for a lot of non linux guys to make their first steps in the asterisk world Crossposted to -users. Zoa Luigi Rizzo wrote: > As a

I am having trouble compiling dahdi-linux-complete-2.9.0+2.9.0.1 on a Raspbien 3.10.25+ kernel. I get the following error - /usr/src/dahdi-linux-complete-2.9.0+2.9.0.1/linux/drivers/dahdi/dahdi-base.c:570:2: error: implicit declaration of function kzalloc [-Werror=implicit-function-declaration] /usr/src/dahdi-linux-complete-2.9.0+2.9.0.1/linux/drivers/dahdi/dahdi-base.c:1391:2: error: implicit

On Mar 19, 2008, at 2:03 PM, Török Edwin wrote: > > What is kext64, and how do I disable it? Comes from: APPLE_LOCAL='APPLE LOCAL libcc_kext' \ MULTILIBS="`$(GCC_FOR_TARGET) --print-multi-lib` static;@static at fno-pic kext;@Dmal loc=kern_os_malloc at Dfree=kern_os_free at DLIBCC_KEXT@static at fno-pic@fno- exceptions at fno-non-ca