BeBits Information Developer Central Submit Application Your Account Web Links Contact Us
BeBits
Please support our sponsors!
gcc
Talkback
 Go back to the gcc page
 Post a new Talkback comment!
Re: 2.95
 By Oliver Tappe - Posted on July 24, 2007 - 16:07:14   (#21845)
 Current version when comment was posted: 3.4.3
Hi Francois,

no, I don't think that this is possible, as the compiler has *not* changed since the last release, only the binutils were updated.

I remember that ffmpeg used to (and still does) cause many problems
with gcc-2.95.3, but I have no plans for fixing these, as that gcc is simply too old to put any more work into it.

Sorry, maybe it's possible to use gcc-4 for it?

2.95
 By mmu_man - Posted on July 23, 2007 - 04:35:13   (#21838)
 Current version when comment was posted: 3.4.3
Is it possible to have it align stack variables at last ? this is needed for ffmpeg... but doesn't work.
void foo() {
...
int bar __attribute__ ((aligned(16)));
just doesn't have any effect.

gcc 3.4.3 & headers
 By tonestone57 - Posted on August 9, 2006 - 23:15:00   (#20354)
 Current version when comment was posted: 3.4.3
I had no problems with gcc 2.95.3 (from Oliver) or the older gcc (from Zeta).

But I noticed that with gcc 3.4.3 that it doesn't use the header files found in /boot/develop/headers (ie: posix, SDL, etc.).

When compiling, I require some of these missing files.

How would I go about setting it up so these header files are found (I tried copying them over to the include folders in gcc 3.4.3, but didn't work).

Is there a way to specify to include header files in /boot/develop/headers (& all subfolders) with gcc 3.4.3???

Any help appreciated, Thanks.

Problem on R5+Bone
 By cvincent - Posted on August 3, 2006 - 11:57:50   (#20282)
 Current version when comment was posted: 3.4.3
Hi, i get some trouble after using the new version of gcc 2.95.3 BeIDE freeze in link and beos too !!
after reinstalling the gcc-2.95.3-beos-041202.zip all done !!
i think that can come from libstdc++.r4.so because beide have problem (and linker) but beos have some troubke (tracker applications etc...)

Re: 3.4.3, objcopy & absolute addresses fails
 By Oliver Tappe - Posted on July 16, 2006 - 06:39:55   (#20161)
 Current version when comment was posted: 3.4.3
Hi pure_void,

I have fixed the problem with grub, such that configure runs through. After what I have found in grub's configure script, I consider it broken for all systems that use position independent code by default (such as BeOS). Using PIC triggers a bug in the 'binary'-backend of binutils, which then leads to the creation of these huge files...
Four steps are needed to circumvent the problem:

1.) Edit the gcc specs (/boot/develop/tools/gnpro/lib/gcc-lib/i586-pc-beos/2.95.3-beos-060710) and change the link-spec (the line following '*link:'. In this line, change '-shared' to '%{!static: -shared}'. This change makes it possible to avoid shared linking by specifying '-static' on the gcc commandline.

2.) Edit the grub configure script and go to the first line that contains '-nostdlib' (for grub-1.94 that is line 6167). On this line change '-nostdlib' to '-static -nostdlib'. This is causing gcc to make use of '-static' in order to avoid linking with '-shared'.

3.) run configure like this:

CPPFLAGS="-I/boot/home/config/include/lzo" TARGET_CFLAGS="-Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes" LDFLAGS="-L/boot/home/config/lib" ./configure --prefix=/boot/home/config

On my machine, that fixed the problem (tested with gcc-2.95.3 though, so your mileage may vary).

4.) edit conf/i386-pc.mk and conf/i386-pc.rmk and search for '-N'. In both files, there you'll find four lines similar to this:

..._LDFLAGS = -nostdlib -Wl,-N,-Ttext,7C00

add '-static ' to all these lines, so they look like that:

..._LDFLAGS = -static -nostdlib -Wl,-N,-Ttext,7C00

I haven't followed through actually compiling grub, as there were some errors when I tried, but I thought I'd leave some work for you... >;o)

If you still encounter problems, please contact me via mail (gcc AT hirschkaefer DOT de).

cheers - Oliver

Re: 3.4.3, objcopy & absolute addresses fails
 By Oliver Tappe - Posted on July 14, 2006 - 15:57:27   (#20153)
 Current version when comment was posted: 3.4.3
Hi pure_void,

I have been able to reproduce the problem with gcc-2.95.3, too, which uses the same binutils.
Cause of the problem may very well be a hack inside of binutils that tries to cope with the fact that BFS does not support enlarging files by seeking to an absolute position and then writing (well, it is supported, but the "empty" bits aren't filled with zeroes, which is required by binutils).
Tomorrow I'll debug objcopy and try to find out what's really going wrong...

cheers, Oliver

3.4.3, objcopy & absolute addresses fails
 By pure_void - Posted on July 14, 2006 - 15:01:03   (#20152)
 Current version when comment was posted: 3.4.3
I'm trying to compile grub, and there's a problem with the test of whether objcopy supports absolute addresses.

Here's the config.log:

configure:3870: checking whether objcopy works for absolute addresses
configure:3883: gcc -c -g -Wall -Wmissing-prototypes -Wunused -Wshadow -Wpointer-arith -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wundef conftest.c >&5
/boot/home/downloads/grub-0.97/conftest.c:3: warning: no previous prototype for `cmain'
configure:3886: $? = 0
configure:3896: gcc -g -nostdlib -Wl,-N -Wl,-Ttext -Wl,2000 conftest.o -o conftest.exec
configure:3899: $? = 0
configure:3907: objcopy -O binary conftest.exec conftest
configure:3910: $? = 0
configure:3896: gcc -g -nostdlib -Wl,-N -Wl,-Ttext -Wl,8000 conftest.o -o conftest.exec
configure:3899: $? = 0
configure:3907: objcopy -O binary conftest.exec conftest
configure:3910: $? = 0
configure:3918: cmp -s conftest.old conftest
configure:3921: $? = 1
configure:3932: result: no
configure:3935: error: GRUB requires a working absolute objcopy; upgrade your binutils

I ran the test myself, and it turns out objcopy generates a 2GB file! I ran DiskProbe on the file, and it's basically just all zeroes in the middle, then some stuff in the first 512bytes, and the last 1KB.

gcc 2.95 + BeIDE
 By kor - Posted on July 16, 2005 - 06:26:46   (#17226)
 Current version when comment was posted: 3.4.3
> Warning : gcc
> installation problem, cannot exec `cpp'
> No such file or directory
> Error : Errors and/or warnings resulted in tool termination

The problem comes from Zeta version of BeIDE.
Replace it with the original BeIDE from BeOS R5 DevKit, and that's ok.

Re: gnat & gcj
 By Oliver Tappe - Posted on April 23, 2005 - 12:16:01   (#16414)
 Current version when comment was posted: 3.4.3
Just to make things clear:

In my post below I was only talking about the gcc-2.95.3 release. I am not in a position to tell anything about the state of gnat & gcj for the 3.4.3 release.

cheers,
Oliver

Re: gnat & gcj
 By Oliver Tappe - Posted on April 23, 2005 - 07:24:29   (#16410)
 Current version when comment was posted: 3.4.3
I've never tried building any of these compilers, so I have no idea how much work would be neccessary to get them working on BeOS.

I've just tried building gcj and that "succeeded" out-of-the-box, *but* I haven't tested the resulting compiler at all.

Gnat, however, seems to not be part of this gcc-distribution. Maybe one has to download it separately, I don't know.

Concerning putting the patches upstream, there are significant problems with a) finding someone that is interested in dealing with this very old version of the compiler (it is from 1999) and b) finding system-independent solutions for some of the patches.
I have talked with the binutils-maintainer and he rightly pointed out several problems with the code that'd need to be fixed before he could accept the patch. Taking into account the fact that BeOS R5 is a dead platform (which is going to be replaced by haiku and/or Zeta), I do not believe it's worth the effort.
I would rather like to do a proper port of gcc-3 (or 4) to haiku R2 (whenever that will materialize).
cheers,
Oliver

gcj
 By Fredde - Posted on April 23, 2005 - 05:04:05   (#16409)
 Current version when comment was posted: 3.4.3
I wonder the same thing about the java part of gcc, gcj. Would it be a lot of work porting it to BeOS?
Do you know if anyone have done any work for getting gcj running on BeOS?
And one final question... Have your patches for current gcc been accepted and put into their repository so that it compiles straight from cvs?

Ada compiler with GCC for beos
 By craftiful - Posted on April 22, 2005 - 21:20:29   (#16408)
 Current version when comment was posted: 3.4.3
I read that GCC for other OSes includes a GNU Ada compiler (named 'gnat') does the beos release of GCC have this?

gcc 3.4.3 on Zeta
 By ModeenF - Posted on March 8, 2005 - 02:40:22   (#16093)
 Current version when comment was posted: 3.4.3
Make gcc 3.4.3 work with Zeta.
include a link tools from /boot/beos/etc/develop/zeta-r1-gcc2-x86 in /boot/beos/etc/develop/gnupro-3.4.3

include a link headers from /boot/beos/etc/develop/zeta-r1-gcc2-x86 in /boot/beos/etc/develop/gnupro-3.4.3

made link folder x86 in/boot/beos/etc/develop/gnupro-3.4.3/lib/ from /boot/beos/etc/develop/zeta-r1-gcc2-x86/lib/x86

I don't know if this is right (i'm only using the terminal and no Be API calls)

when I try to make a projec (alt+m)
I get this error
Error : /boot/develop/lib/x86/start_dyn.o(.text+0x60): In function `_start':
: undefined reference to `main'
Error : /data/work/c++/inlupp/terminal/(Objects.terminal)/terminal.o(.text+0xb77): In function `terminal_star85::terminal::terminal(void)':
: undefined reference to `cerr'

etc (long error list)
I have libstdc++.a from gcc3.4.3 last in the project

the line (only place with cerr)looks like this
std::cerr << "Attempt to reinitiate terminal!" << std::endl;

@memson
 By ahwayakchih - Posted on March 7, 2005 - 16:08:04   (#16091)
 Current version when comment was posted: 3.4.3
There is "patch" subdirectory in 3.4.3 zip. It contains all the diffs. There's also README file in the zip, in which i tried to describe which diff is for what. I hope that helps :).

@ahwayakchih
 By memson - Posted on March 7, 2005 - 15:15:07   (#16090)
 Current version when comment was posted: 3.4.3
Is there a diff file or better still, source build for GCC 343?? I want to patch the backend for another compiler target (D comiler GDC) and when I had your pre release version, I didn't get it to work. With the BeOS port/diffs I may have a better chance ;-)

Matt

Thanks!
 By jonas.kirilla - Posted on February 23, 2005 - 22:54:11   (#15948)
 Current version when comment was posted: 3.4.3
Great work, Oliver!

Without your gcc work I wouldn't have been able to compile Taglib on either R5 or Zeta.

re: Using both
 By ahwayakchih - Posted on February 23, 2005 - 06:48:50   (#15942)
 Current version when comment was posted: 3.4.3
You can't mix C++ code/libs made with GCC 2.x and 3.x - they use different ABI and that's why You get errors.

But if You want to use GCC 3.x, and You need just a few BeOS C++ API functions, it's easy to write "wrapper"/"bridge" library for that. I used that way for Wesnoth game.
So:
- Write C functions wrapping BeOS C++ API functionality You need, and build library using GCC 2.x.
- From the code compiled and linked with GCC 3.x call functions exported by Your "wrapper" library (instead of calling Be C++ API directly).

That should work. Just remember to make that "wrapper" library pure C (that's the whole point of making it, C++ will not work :).


Using both
 By execom - Posted on February 23, 2005 - 05:58:23   (#15941)
 Current version when comment was posted: 3.4.3
Well, i've done some more tests.

Apparently using GCC 3(for cross platform code) + GCC 2.95 (for BeOS specific code) code is very random :

Sometimes it works (no link errors), sometimes, I have the gxx_personality_v0 link error comes up.

If i'm create an application composed of a mix of GCC 3. and GCC 2 libraries, the linker is simply going mad up, claiming unresolved references, even with a correct ordering of the libraries.

So I will stick to GCC 2.95 and waits for the version with anonymous structures (changing to non anonymous would break too much code).

Is someone was thinking about a 'thunk' layer for BeOS for using GCC 3 : I means create new headers, GCC 3. x compatible, and when calling a BeOS API, it will use an intermediate class that will call the BeOS API ?)




Re: cross compilation
 By Oliver Tappe - Posted on February 21, 2005 - 08:38:30   (#15920)
 Current version when comment was posted: 3.4.3
> Is it possible to have a configuration where GCC 3.4 is the
> default compiler and using that parameter (-V) in the
> command line when I want to compile BeOS specific code.
>
> Is that possible ? How to configure my environment then ?

Yes, I think this should be possible. All you need to do is to copy the folder .../lib/gcc-lib/i586-pc-beos/2.95.3-beos-041202 into the respective gcc3-folder, as this folder contains the version-specific files for gcc. It should then be possible to run this version like this:

gcc -V 2.95.3-beos-041202 files_and_other_options...

However, with the specific problems gcc-3 currently has under BeOS, I wouldn't recommend such a setup at all, since I am not sure that the separation between the two compilers is good enough to deal with the different headers that are used for gcc-3.

> Last thing, the GCC 2.95 has a quite buggy linker which
> requires a certain order of the objects files in order to
> link. Else, it will produce undefined symbols when linking,
> but reordering in the BeIDE makes the things better.
>
> For example
>
> library1.a (which exports a global variable A)
> library2.a (defines a global variable A)
>
> Will produces a linker error.Because of the order in not
> correct (needs to be re-orderered to library2.a,
> library2.a).

I believe this is no bug, but it is correct behaviour. Order is not relevant when linking object-files (*.o), but it *is* relevant when linking (static) libraries (*.a), since the linker only takes from libraries what it needs at the time it links the library (leading to the error you experienced since some symbols were references after the library had been linked).

> Is is safe to use the updated GCC 3.4 linker rather that the
> one of GCC 2.95 ? (which fixed that problems).

Yes, it's safe, as it's actually basically the same linker (ld-2.15). I doubt that switching linkers fixed your problem, something else probably did.

cheers,
Oliver

Zeta or BeOS
 By execom - Posted on February 21, 2005 - 05:53:52   (#15916)
 Current version when comment was posted: 3.4.3
Yes,
So instead of defining -D_ZETA, for example in this code:

status_t POSTMESSAGE(BLooper *p, BMessage *m)
{
#if B_BEOS_VERSION < 0x0520
return p->PostMessage(m);
#else
BMessenger messenger(p);
return messenger.SendMessage(*m);
#endif
}

Will be a better solution

cross compilation
 By execom - Posted on February 21, 2005 - 05:50:46   (#15915)
 Current version when comment was posted: 3.4.3
OK for detecting BeOS version (because Zeta and BeOS are not compatible to each other - mainly due to the 'PostMessage' deprecated API. There is a workaround using SendMessage, but it doesn't compiles on R5.

Apparently there is a GCC_VERSION defined somewhere, needs to have a closer look.

In GCC, there the compiler parameter called:
-V version

http://www.dis.com/gnu/gcc/Target-Options.html#Target%20Options

Is it possible to have a configuration where GCC 3.4 is the default compiler and using that parameter (-V) in the command line when I want to compile BeOS specific code.

This let me be able to switch between GCC 3 and GCC 2 without changing everytime the symbolic link to gnupro .

Is that possible ? How to configure my environment then ?

Last thing, the GCC 2.95 has a quite buggy linker which requires a certain order of the objects files in order to link. Else, it will produce undefined symbols when linking, but reordering in the BeIDE makes the things better.

For example

library1.a (which exports a global variable A)
library2.a (defines a global variable A)

Will produces a linker error.Because of the order in not correct (needs to be re-orderered to library2.a, library2.a).

Is is safe to use the updated GCC 3.4 linker rather that the one of GCC 2.95 ? (which fixed that problems).

Else would this bug will ever be fixed ?


re: link error sorted
 By ModeenF - Posted on February 21, 2005 - 05:37:17   (#15914)
 Current version when comment was posted: 3.4.3
Hade a look in Zeta 2.95's BeBuild.h and this is what I found
#define B_BEOS_VERSION_4 0x0400
#define B_BEOS_VERSION_4_5 0x0450
#define B_BEOS_VERSION_5 0x0500
#define B_BEOS_VERSION_5_0_4 0x0504
#define B_BEOS_VERSION_5_1_0 0x0510
#define B_ZETA_VERSION_0_2_0 0x0520
#define B_ZETA_VERSION_0_3_0 0x0530
#define B_ZETA_VERSION_0_4_0 0x0540
#define B_ZETA_VERSION_0_4_1 0x0541


#define B_BEOS_VERSION_MAUI B_BEOS_VERSION_5
#define B_BEOS_VERSION_DANO B_BEOS_VERSION_5_1_0
#define B_ZETA_VERSION_BETA B_ZETA_VERSION_0_2_0
#define B_ZETA_VERSION_GESTALT B_ZETA_VERSION_0_3_0
#define B_ZETA_VERSION_BELLA B_ZETA_VERSION_0_4_0
#define B_ZETA_VERSION_NEO B_ZETA_VERSION_0_4_1

#define B_ZETA_VERSION B_ZETA_VERSION_NEO
#define B_BEOS_VERSION B_ZETA_VERSION

Is this the information we need?

re: link error sorted
 By ahwayakchih - Posted on February 21, 2005 - 04:34:51   (#15913)
 Current version when comment was posted: 3.4.3
on BeOS You have:

__BEOS__

symbol and:

B_BEOS_VERSION

(look into BeBuild.h file).

On BONE (Dano and probably also Zeta) You also get:

BONE_VERSION


link error sorted
 By execom - Posted on February 21, 2005 - 04:10:54   (#15912)
 Current version when comment was posted: 3.4.3
I've fixed the problem by defining .
int __gxx_personnality_v0;

Also how to detects which version of compiler I'm using

Like doing
#if GCC < 3.0
GCC 3.0 code
#else
GCC 2.95 code
#endif


Same how to detects that a code is compiled under BeOS Zeta or BeOS R5 or other ?



re: GCC 2.95.3 + GCC 3.4.3
 By ahwayakchih - Posted on February 20, 2005 - 07:39:44   (#15905)
 Current version when comment was posted: 3.4.3
Try to also link to libstdc++ when using gcc 3.x.

GCC 2.95.3 + GCC 3.4.3
 By execom - Posted on February 20, 2005 - 06:59:35   (#15904)
 Current version when comment was posted: 3.4.3
For the / stray bug, i've just added comment 'please convert to unix' format.

Another question.
I've installed GCC 3.4.3 and the latest version of GCC 2.95.3

Basically, i'm doing this:
I've created a link call /boot/develop/tools/gnupro that link to gcc-2.95.3-binutils-2.15

By doing Get Info and dragging either gnupro-3.4.3 or gnupro-2.95.3 folder to the 'Link To' line, i can dynamically switch between the two system

Now, i've got a BeOS program, but most of the code is C and independant of BeOS.

So I'm made a project that create a static library, using GCC 3.4
and a project that create an application or a shared library that links that 'GCC 3' 'C static library'

Code compiles on both, but when linking I have:

Error : /boot/home/xxxxx.a (xxxx.o)(.gnu.linkonce.d.DW.ref.__gxx_personality_v0+0x0) : undefined reference to '__gxx_personality_v0'

what the hell is that ?
Can it be solved ?




Re: gcc-2.95.3 and DOS-newlines
 By Oliver Tappe - Posted on February 20, 2005 - 06:07:28   (#15903)
 Current version when comment was posted: 3.4.3
I have looked at the problem yesterday and it can be solved by using cpplib instead of the (old) cpp. However, this leads to other problems when compiling haiku. Fixing the problem in cpp isn't trivial, as it requires changes in many places.

So I recommend to either use gcc-3 or simply convert all your input files to unix newlines.

GCC 2.95.3
 By execom - Posted on February 19, 2005 - 07:50:03   (#15896)
 Current version when comment was posted: 3.4.3
Just tried your version 2.95.3, but still got the

anonymous class type not used to declare any objects that bugs me, even when forcing to C++ compilation of C code.

I'm not too familiar for get CVS. Can you prepare a package for me ?

Do you plan also to fix the 'stray \in program' bug as well ?

It happens with GCC when compiling a C/C++ file in DOS format and multiline macro
for example
#define MY_MACRO(x) \
(x)

This generate a a 'stray '\' in program fatal error'.
I need to change the file format to 'Be' in order to compile.

This bug was fixed in GCC 3



Re: GCC 2.95.3 and anonymous structure
 By Oliver Tappe - Posted on February 19, 2005 - 07:02:34   (#15895)
 Current version when comment was posted: 3.4.3
I have applied the patches that were neccessary to enable support for anonymous structs just now. They will be part of the next release, but it is still unclear when that will be published.

So, if you need this urgently, I suggest you fetch the gcc-sources from the haiku-CVS and compile them yourself (or just bug me to make the release soon >:o).

gcc source
 By korli - Posted on February 18, 2005 - 15:41:31   (#15888)
 Current version when comment was posted: 3.4.3
http://cvs.sourceforge.net/viewcvs.py/open-beos/buildtools/

GCC 2.95.3 and anonymous structure.
 By execom - Posted on February 18, 2005 - 08:08:08   (#15887)
 Current version when comment was posted: 3.4.3
Does the GCC 2.95.3 has the anonymous structure patch

As described here ?
http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg00914.html

I really need this features.

Thanks;

Else, where is the source of the package ?

Re: gcc 2.95 and Zeta
 By Oliver Tappe - Posted on January 16, 2005 - 13:34:01   (#15439)
 Current version when comment was posted: 3.4.3
Hi gmiranda and SHINTA,

sorry it took me so long to react...

could you please send me the output of

ls -lR /etc/develop

This would help me a lot in order to find out what's going wrong.

cheers,
Oliver

Re: gcc 2.95 and Zeta
 By SHINTA. - Posted on January 16, 2005 - 05:08:14   (#15430)
 Current version when comment was posted: 3.4.3
me, too...

under Zeta Neo.

2 SD
 By ahwayakchih - Posted on January 4, 2005 - 04:34:03   (#15278)
 Current version when comment was posted: 3.4.3
:)

And the same binary works ok on r5+BONE?
Also have You tried building some other application and checking if it works?
Does mozilla building scripts/whatever use libtool or similar thing which tries to build whole linker commandline by itself (instead of just calling gcc/g++)?

One thing i noticed is that in older gcc's specs file -lnet was before -lroot, while in new it's after -lroot. I doubt it can have any impact but maybe it's worth a try to change order to old one? :)

2 ahwayakchih
 By SD - Posted on January 3, 2005 - 18:19:22   (#15273)
 Current version when comment was posted: 3.4.3
(Shard was much easier to type and pronounce, wasn't so?:)
here is exactly what it says:
Tracker:
Could not open "mozilla-bin" with application "mozilla-bin" (Not an executable)
Shell:
/dist/bin/run-mozilla.sh: ./mozilla-bin: cannot execute binary file

Syslog
Jan 4 02:03:46 Roster::LaunchApp: loading image failed (0x80001302). Not an executable

gcc 2.95 and Zeta
 By gmiranda - Posted on January 3, 2005 - 16:50:29   (#15272)
 Current version when comment was posted: 3.4.3
Hi! I've managed to install your gcc under R5, but not under Zeta (RC3). When I try to build something under BeIDE I get tons of errors like this:

Warning : gcc
installation problem, cannot exec `cpp'
No such file or directory
Error : Errors and/or warnings resulted in tool termination

Do you know what went wrong? :(
I've tried in 2 differents computers

re: missing symbol - right, but
 By s_d - Posted on January 3, 2005 - 16:31:32   (#15271)
 Current version when comment was posted: 3.4.3
that's true, i didn't get sumbol names in shell.
But IIRC i got just that message itself - "missing symbol".
But not in mentioned case.

re: missing symbol
 By ahwayakchih - Posted on January 3, 2005 - 15:10:37   (#15270)
 Current version when comment was posted: 3.4.3
Hmm.. i never get missing symbol name in Terminal. Did You try to run it from Tracker?

missing symbol
 By SD - Posted on January 3, 2005 - 14:38:04   (#15269)
 Current version when comment was posted: 3.4.3
Usually i'm getting explicit message in Terminal in such cases, which just says: "missing symbol - foo". But not in this case.
I will try to rebuild Mozilla once more with gcc 2.953 under betserver, but maybe any additional clue/advise, to do this problem hunting more effective?

re: 2.95.3 and Mozilla - "cannot execute binary"
 By Oliver Tappe - Posted on January 3, 2005 - 12:44:09   (#15265)
 Current version when comment was posted: 3.4.3
The "cannot execute binary" usually means that a required symbol wasn't found when starting the apps.

If you have syslogging enabled, /var/log/syslog should give you more info about what symbol is missing.

Please send that info to me such that I can find out what's going wrong.

cheers,
Oliver

Comment Pages:    << prev  |  1  |  2  |  next >>
 
The Green Board
  Recent Downloads  -  # 50
Total Downloads  -  # 527
Total Views  -  # 228
User Ratings  -  N/A
  Dev. Languages
1.  QEMU - 9.62
2.  ScummVM - 9.50
3.  cpu_fix - 9.42
4.  Jukebox - 9.36
5.  Haiku AGP busm... - 9.35
6.  vim6 - 9.31
7.  Transmission - 9.27
8.  Beezer - 9.25
9.  BeeF - 9.25
10.  HandBrake - 9.24
1.  Ati Radeon Grap... - 422
2.  BeOS 5 Personal... - 237
3.  Realtek RTL8139... - 226
4.  USB Serial driver - 175
5.  ATI Rage 128 Pr... - 158
6.  VLC Media Player - 118
7.  Ensoniq AudioPC... - 102
8.  Sound Blaster Pr... - 92
9.  Broadcom 440x 10... - 91
10.  S3 Trio 64 v2 DX... - 87
You are not logged in.
 Login or create an account...
Hosted by NetConnect

 
Unless otherwise noted, everything is copyright © 1999-2002 Fifth Ace Productions, LLC. All Rights Reserved.
For more legal trivia, take a gander at our
Legal Stuff page and our Privacy Statement.
Fifth Ace Productions