Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nyargh]

Right out of the gate, configure barfs:

Code: [Select]

-bash-3.00$ ./configure
checking build system type... i386-unknown-openbsd3.6
checking host system type... i386-unknown-openbsd3.6
checking target system type... i386-unknown-openbsd3.6
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
./configure[1868]: : bad substitutionCommenting out the offending lines gets configure running:

Code: [Select]

*** configure~  Tue Oct 19 16:11:58 2004
--- configure   Tue Oct 19 16:11:58 2004
***************
*** 1867,1870 ****
  # No -O2 by default, removing -fomit since it causes problems
! CFLAGS=" ${CFLAGS/-fomit-frame-pointer/}"
! CXXFLAGS=" ${CXXFLAGS/-fomit-frame-pointer/}"
 
--- 1867,1870 ----
  # No -O2 by default, removing -fomit since it causes problems
! #CFLAGS=" ${CFLAGS/-fomit-frame-pointer/}"
! #CXXFLAGS=" ${CXXFLAGS/-fomit-frame-pointer/}"
Then, not even a minute into it, another failure:

Code: [Select]

gcc -DHAVE_CONFIG_H -I. -I. -I../../..   -I/usr/local/include   -g -O2 -W -Wall -g -ggdb -fno-inline -D__DEBUG__ -fmessage-length=0 -O2  -c -o cas-cas.o `test -f 'cas.c' || echo './'`cas.c
cc1: Invalid option `-fmessage-length=0'
gmake[5]: *** [cas-cas.o] Error 1
-bash-3.00$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.6/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)...
Alright, --disable-debug seems to take care of that (debug by default?), but now we get:

Code: [Select]

gcc -DHAVE_CONFIG_H -I. -I. -I../../..   -I/usr/local/include   -g -O2  -O2  -c -o cas-html.o `test -f 'html.c' || echo './'`html.c
html.c: In function `create_html':
html.c:58: syntax error before `char'
This was "cross-platform"... er... how, again?

Fine, screw CAS, who needs pretty pictures anyway?  Lets just try and get this pig built...

--enable-daemon --disable-debug --disable-cas --disable-wxcas

Code: [Select]

g++ -DHAVE_CONFIG_H -I. -I. -I../../../..   -I/usr/local/include -I/usr/local/lib/wx/include/gtk-2.5 -I/usr/local/include -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__OPENBSD__ -DUSE_EMBEDDED_CRYPTO    -c -o alc-alcframe.o `test -f 'alcframe.cpp' || echo './'`alcframe.cpp
In file included from alcframe.cpp:56:
md4.h:57: stdint.h: No such file or directory
Okaaaayyy... don't need the link creator either... I guess..

--enable-daemon --disable-debug --disable-cas --disable-wxcas --disable-alc --disable-alcc

Wow, it seems to be actually building!

Oh wait, too good to be true....

Code: [Select]

g++ -DHAVE_CONFIG_H -I. -I. -I..   -I/usr/local/include -I/usr/local/lib/wx/include/gtk-2.5 -I/usr/local/include -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/local/lib/wx/include/gtk-2.5 -I/usr/local/include -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DAMULE_DAEMON  -D__OPENBSD__ -DUSE_EMBEDDED_CRYPTO    -c -o amuled-UploadQueue.o `test -f 'UploadQueue.cpp' || echo './'`UploadQueue.cpp
UploadQueue.cpp: In method `void CUploadQueue::AddUpNextClient(CUpDownClient * = 0)':
UploadQueue.cpp:111: `::find' undeclared (first use here)


Oh well...

At least mldonkey can compile and run... :rolleyes:

[Kry]

The *BSD ports should be on it's way. Anyway, some of your problems come from old gcc (2.95) and old libc.

[nyargh]

Unfortunately gcc 2.95.3 and libc 34.1  are the standard versions in the latest release of OpenBSD (to be released Nov. 1 '04).  

Might want to take OpenBSD off of your supported platforms list unless you want to add some #ifdef blocks to work around the gcc issues -- it's not really reasonable to ask folks to upgrade their libc and gcc just to get your app to compile.  I know that stable 3.x gcc has been out for a while now, but the OpenBSD maintainers tend to be on the (highly) conservative side of upgrading major components.  

[lfroen]

Few advises: if "configure" is failing so badly why not run "autogen" and re-create it with correct definitions for your system (like compiler flags ) ?

UploadQueue.cpp:111: `::find' undeclared (first use here)

What version of stl is that ?

gcc 2.95.3 is 3 year old !

Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.6/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)...

gcc 3.x in some cases will refuse to compile code that 2.95 will accept. In this situation I preffer 3.x version.

And yes, it's "all platform" but sure not "all compiler / all libc"; event not "all wx / all gtk"

[Jacobo221]

"I know that stable 3.x gcc has been out for a while now" <- year for a _LONG_ while. even rumours about going up to gcc4 are old.
OpenBSD is supported since upgrading to libc is not a problem. but ye, maybe some #ifdefs should be added too. Anyway, there's been no-one opneBSD-programmer to check this release so it will compile almost for sure after some few tricks but contributors are needed to help on next releases.
Greetings!

[nyargh]

I'm happy to help, as clearly I'm interested in aMule and have a current OpenBSD environment.  Unfortunately, I'm not very familiar with either the codebase nor the caveats for porting from gcc 2.95 to 3.x.

It's possible the differences between 2.95 and 3.x are be what's preventing the OpenBSD folks from upgrading as well.  Since this release (OpenBSD 3.6) just came out, it's doubtful that 3.x is on the roadmap soon, but I'll ping those folks to see if it is being considered.

Few advises: if "configure" is failing so badly why not run "autogen" and re-create it with correct definitions for your system (like compiler flags ) ?

I re-ran autoconf with the same results, did I need to run autogen instead?

It seems those flags were explicitly defined in configure.in w/o considering any AC_xxx defines, so I'm not surprised that regenerating configure didn't make a difference.

And yes, it's "all platform" but sure not "all compiler / all libc"; event not "all wx / all gtk"

OpenBSD is a picky distro, built explicitly with security in mind.  It is not FreeBSD, despite first glance appearances.  The libc is heavily patched, and gcc is has even been tweaked for a year now for default propolice stack protection.  Ironically, it's an ideal environment to run inherantly insecure P2P applications (not pointing out aMule in particular, it's just the nature of the beast...), and it would be a Good Thing good to support OpenBSD for that reason alone.

As far as libc/gcc, it's assumed that there's a bit more consistancy w/ ANSI C vs. wxwidgets and certainly gtk.  Libc/gcc (back)portability should be a much easier target to hit in that regard, at least.  There's also the matter of dependancies, which makes most admins very weary to screw around w/ libc too often - and OpenBSD folks simply can't do it easily or safely due to the forked codebase.

So uh... we can argue the definition of "platform", but OpenBSD - for better or for worse -  has some other issues to tackle from the compatibility end of things, before you can really list it as "supported".

[nyargh]

What version of stl is that ?

Is this what you're looking for?

Code: [Select]

#define _G_LIB_VERSION "2.9.0"

[lfroen]

It seems those flags were explicitly defined in configure.in w/o considering any AC_xxx defines, so I'm not surprised that regenerating configure didn't make a difference.

amule doesn't define any flags explicitly. So you can blame for it your gtk and/or wx.

It's possible the differences between 2.95 and 3.x are be what's preventing the OpenBSD folks from upgrading as well.

I hope you don't expect from amule team to move back to 2.95, didn't you ? Sorry to disappoint you, but most of other distros did moved to 3.x, and it's not reasonable to support both.

OpenBSD is a picky distro, built explicitly with security in mind. It is not FreeBSD, despite first glance appearances. The libc is heavily patched, and gcc is has even been tweaked

And here is the price you pay - application compatibility. No free lunch as you see

[nyargh]

I hope you don't expect from amule team to move back to 2.95, didn't you ? Sorry to disappoint you, but most of other distros did moved to 3.x, and it's not reasonable to support both.

Then you should definitely drop OpenBSD from your supported platforms list!

And here is the price you pay - application compatibility. No free lunch as you see

Erm...

Code: [Select]

-bash-3.00$ wc -l /usr/ports/INDEX
    2688 /usr/ports/INDEX

amule doesn't define any flags explicitly. So you can blame for it your gtk and/or wx.

Really?  configure.in looks pretty kludgy to me...

Code: [Select]

-bash-3.00$ ./configure
checking build system type... i386-unknown-openbsd3.6
checking host system type... i386-unknown-openbsd3.6
checking target system type... i386-unknown-openbsd3.6
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
./configure[1868]: : bad substitution
from configure.in:

Code: [Select]

# No -O2 by default, removing -fomit since it causes problems
CFLAGS=" ${CFLAGS/-fomit-frame-pointer/}"
CXXFLAGS=" ${CXXFLAGS/-fomit-frame-pointer/}"
This blows chow right out of the gate.

Anyhow, it sure is easier to point fingers than fix compatability issues, or recuit help from others.  Such is the downfall of many an open source project.


Adios...

[Kry]

I'm sorry that some people gets to dissapoint users so badly ¬¬


I would love nyargh to come back and we should use his enviroment to achieve OpenBSD compatibility. And yes, there are flags on configure.in, something people should check before blaming others.


If we have to achieve gcc 2.9x compatibility for supporting OpenBSD, we MUST achieve if, either via ifdef's for the platform or whatever.

[nyargh]

I'm pretty much done with this thread, but I thought I'd give you all the official word on gcc 3.x on OpenBSD:

http://www.openbsd.org/faq/upgrade-minifaq.html#1.8

If you follow the link, you'll see this is non-trivial.  You need to pull down and install the source tree and (re)build gcc3 from it, then rebuild your entire tree.

And an important note from the link:

Some platforms will be switching to gcc3 in the future, but some are unlikely to ever switch, due to lack of gcc3 support.

I doubt they're referring to i386 here, but it's clear that gcc3 won't be on the roadmap for at least a few of their platforms.

Again, if you want to abandon a section of your userbase, be up front about it - that is certainly your perogative as developers.  Just realize how silly it sounds to still list OpenBSD as "supported", only to attach absurd caveats like these:

Step #1: build gcc3 from the OpenBSD source tree.  
Step #2: Do a make build at the root of the entire OpenBSD source tree with gcc3 and install your new operating system.  
Step #3: Attempt to compile aMule

 :rolleyes:


Edit:

Ok, while this all looks absurd to me... it seems that maybe it is. Now it looks like OpenBSD does in fact distribute a gcc3 package  

I'll test it and let you all know.  :]

[Xaignar]

Can anyone fix the substitution issue? I'm not autoconf buff, and it seems my approch is flawed. All we need is to ensure that the flag -fomit-frame-pointer isn't in the C(XX)Flags.

[Kry]

Fixed on cvs by me