Allegro 4.1.16 and FreeBSD

Allegro 4.1.16 and FreeBSD

Squirrel Havoc

Member #3,032

December 2002

Hi there, I am having a problem compiling the latest WIP of Allegro with FreeBSD.

First I type "./configure", and all is well. Then I type "gmake", and it starts building. But after a bit, I get this error:

src/unix/usystem.c: In function `_unix_get_executable_name':
src/unix/usystem.c:349: warning: implicit declaration of function `ioctl'
src/unix/usystem.c:349: error: `PIOCPSINFO' undeclared (first use in this function)
src/unix/usystem.c:349: error: (Each undeclared identifier is reported only once
src/unix/usystem.c:349: error: for each function it appears in.)
gmake: *** [obj/unix/shared/alleg/usystem.o] Error 1

I don't know much about unix programming like I do windows, so I can't make changes to the source file that has the error. What should I do?

I am running FreeBSD 5.2.1, with GCC 3.3.3 (please tell me this isn't a GCC bug, I don't have the free space to upgrade it yet).

I also tried the latest stable version, and got a different error. Don't remember what it was though...

Please help, so I don't have to go back to windows for game programming!

Evert

Member #794

November 2000

It's not a problem with GCC.

Can you add #include <sys/ioctl.h> to the top of allegro/src/unix/usystem.c file (it should go to line 45 if you're strict about it) and see if that fixes the problem?

EDIT: what errors were you getting with 4.0.3? I assume that's what you meant by latest stable...?

Squirrel Havoc

Member #3,032

December 2002

Hmm, I added the #include (which wasnt there, so I thought it was whats wrong), but I get the same error.

About 4.0.3, I am building now, I will let you know what it says. i have a slow system

EDIT: That's weird, 4.0.3 built this time. I guess I just gotta wait till the next WIP and hope they fix the error. Thanks for your help

Evert

Member #794

November 2000

Quote:

Hmm, I added the #include (which wasnt there, so I thought it was whats wrong), but I get the same error.

That's very strange. Can you check if there is a /usr/include/sys/ioctl.h on your system? Also, do you get exactly the same error, or only about PIOCPSINFO?

Quote:

That's weird, 4.0.3 built this time.

That's a relief

Quote:

I guess I just gotta wait till the next WIP and hope they fix the error.

Well, that include should really be there regardless, but if it doesn't fix the problem we'll need to look further. Problem is, I don't have acces to a BSD system. I'll look around and get back to you if I think of something else to try.

In the mean time, you can remove the line with #define ALLEGRO_HAVE_SV_PROCFS from allegro/include/allegro/platform/alunixac.h. This will disable the ioctl procfs and make Allegro build cleanly, but you may have to reconfigure allegro with ./configure --enable-magicmain if you want to use get_executable_name().

EDIT: Can you try with adding #include <sys/ioctl.h> and #include <fcntl.h>?

Squirrel Havoc

Member #3,032

December 2002

Hmm I tried adding those includes, but got the same error message.

Evert

Member #794

November 2000

I don't really get this... can you send me your /usr/include/sys/ioctl.h file?
Also, can you try running grep PIOCPSINFO *.h from both /usr/include and /usr/include/sys?
My e-mail addres is in Allegro's documentation, or you can ask me via private message.

Squirrel Havoc

Member #3,032

December 2002

grep in both directories produced no results. Ill dig up the file and email it to you later, I'm gonna be gone all day. I'll look into it when I get back.

Evert

Member #794

November 2000

Take your time. Thanks for spotting this problem and helping out.
Can you test the attached replacement for src/unix/usystem.c? It's a quick hack that I hope compiles and works on BSD (note: I haven't even been able to try to compile the code, let alone run it myself). If this compiles, can you check that get_executable_name() returns the expected result? If it doesn't, can you send me the error messages from the compiler?

Milan Mimica

Member #3,877

September 2003

Quote:

That's very strange.

Strange is not enough.

Check this out:
1)
kanta:/usr/include# grep prpsinfo * -R
elf.h:#define NT_PRPSINFO 3 /* Contains copy of prpsinfo struct */
linux/elfcore.h:struct elf_prpsinfo
linux/elfcore.h:typedef struct elf_prpsinfo prpsinfo_t;
sys/procfs.h:struct elf_prpsinfo
sys/procfs.h:typedef struct elf_prpsinfo prpsinfo_t;

There is no prpsinfo, only elf_prpsinfo.

2)
./configure for procfs never fails for me. It always outputs:
checking sys/procfs.h usability... yes
checking sys/procfs.h presence... yes
checking for sys/procfs.h... yes
... although "prpsinfo" is undeclared

3)
I added a lame line in src/unix/usystem.c just to get some compiling errors, but it compiled fine

#ifdef ALLEGRO_HAVE_SV_PROCFS
   i'd like to get some errors
   #include <sys/procfs.h>
#endif

--
M.M.
http://sparklet.sf.net

Squirrel Havoc

Member #3,032

December 2002

Now I get this error:

src/unix/usystem.c:360:39: missing terminating " character
src/unix/usystem.c: In function `_unix_get_executable_name':
src/unix/usystem.c:361: error: syntax error before "kvm_close"
gmake: *** [obj/unix/shared/alleg/usystem.o] Error 1
localhost#

Ofcourse, thats a typo, even I can fix that Line 360 becomes:

snprintf(filename, 1024, "%s", argv[0]);

It's building now, got past usystem.c, I'll let you know how it goes...

EDIT: Got this error all of the sudden:
src/x/xvtable.c: In function `_xwin_lock':
src/x/xvtable.c:144: error: structure has no member named `locked_thread'
src/x/xvtable.c:144: warning: implicit declaration of function `pthread_self'
gmake: *** [obj/unix/shared/alleg/xvtable.o] Error 1

Don't know how to fix this one...

Evert

Member #794

November 2000

Quote:

Strange is not enough.

Check this out:

Let me guess: you tried it on Linux
Linux doesn't have a System V procfs, and that code isn't used on Linux (and wouldn't work there either). So the changes you made are irrelevant if you compile your code on Linux. Not sure why configure says something else though, although clearly it does write the correct output to the alunixac.h include file... I'll have to look into that.

Quote:

It's building now, got past usystem.c, I'll let you know how it goes...

Yay!

Quote:

Don't know how to fix this one...

I think it's a similar problem. The xwin struct is declared in include/xalleg.h. The locked_thread element is probably declared between #ifdef guards which are missing from xvtable.c. That's my guess though, I'll see if I can take a look at the code tomorrow, it's late.

Again, thanks for helping out

EDIT: yes, that was the problem. Can you try the attached replacement?

Squirrel Havoc

Member #3,032

December 2002

Hmm, the library built, but I get this new error i think when its building the demo:

lib/unix/liballeg-4.1.16.so: undefined reference to `kvm_open'
lib/unix/liballeg-4.1.16.so: undefined reference to `kvm_getargv'
lib/unix/liballeg-4.1.16.so: undefined reference to `outportw'
lib/unix/liballeg-4.1.16.so: undefined reference to `kvm_close'
lib/unix/liballeg-4.1.16.so: undefined reference to `kvm_getprocs'
gmake: *** [demo/demo] Error 1

Evert

Member #794

November 2000

Ah, ok, that is a missing dependency. Almost there now. Can you see if there's a libkvm.a in either /usr/lib or /usr/local/lib? If so, can you add -lkvm LIBS in the makefile?

Squirrel Havoc

Member #3,032

December 2002

Well, we're getting closer I added the -lkvm to 2 different spots in the makefile, one for allegro, one for the programs built with allegro. Now I am getting this error:
gcc -s -L/usr/X11R6/lib -Wl,-export-dynamic -o demo/demo obj/unix/demo.o -Llib/unix -lalleg-4.1.16 -lalleg_unsharable -lm -lkvm
lib/unix/liballeg-4.1.16.so: undefined reference to `outportw'
gmake: *** [demo/demo] Error 1

EDIT: I am attatching the makefile, incase I screwed something up

Evert

Member #794

November 2000

The makefile looks fine to me. It looks like Allegro is trying to use another Linuxism. Can you try passing the --disable-vga flag to configure?

Squirrel Havoc

Member #3,032

December 2002

Hmm, did what you said, and I think this is the same error:

gcc -s -L/usr/X11R6/lib -Wl,-export-dynamic -o demo/demo obj/unix/demo.o -Llib/unix -lalleg-4.1.16 -lalleg_unsharable -lm -lkvm
lib/unix/liballeg-4.1.16.so: undefined reference to `outportw'
gmake: *** [demo/demo] Error 1

Evert

Member #794

November 2000

Strange. The only location where I can see outportb being used (in Linux) are the VGA and Mode-X drivers. I can't find any reference for this using a quick google, so I'm at a loss to figure out how to work around this at the moment.
I'm going to see if I can get access to a BSD machine to try to compile the code myself and see what I can come up with. In the meantime, can you send me the output from configure? I'd like to see what it reports.

Kitty Cat

Member #2,815

October 2002

4.1.16 has the problem of not properly figuring out what code to include or not include when certain drivers are disabled. I posted a patch to AD a while ago that fixes that issue, but I don't think anyone's tried it out yet.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Evert

Member #794

November 2000

Good point, may be worthwhile to check this again with your patch applied.
I'm curious though, these problems suggest to me that the BSD port has been broken for a while now... maybe I should complain about still not having access to SF's compile farm; it'd really save time if we could test code immediately on multiple platforms.

Squirrel Havoc

Member #3,032

December 2002

I'm using the latest stable branch right now (cant remember the version number). I am trying to run grabber, and get a screen flooded with this error repeated a lot:

grabber in free(): error: recursive call
Bus error (core dumped)

right when I start it up, fullscreen or windowed, that happens before I can do anything. I perused the grabber sourcefile, and saw no mention of this error, so I assume its not an allegro error, but a compiler system thing.

I am running XFree86 with KDE 3.3, on FreeBSD 5.2.1 still.

Evert

Member #794

November 2000

That won't really help in working out the kinks in the latest WIP though - and I'd rather focus on that at the moment.
Can you do what I asked in my previous message, send me the configure output from a clean 4.1.16 WIP install?

Squirrel Havoc

Member #3,032

December 2002

Here is the config output with the latest WIP:

localhost# ./configure --disable-vga
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether -fomit-frame-pointer is safe... yes
checking whether an include prefix is needed... yes
checking how to run the C preprocessor... gcc -E
checking whether a C++ compiler is installed... yes
checking whether linker works with -s option... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking whether ln -s works... yes
checking for ldconfig... /sbin/ldconfig
checking for makeinfo... /usr/bin/makeinfo
checking for install-info... /usr/bin/install-info
checking for processor type... i386
checking whether -mtune is supported... no
checking for MMX support... yes
checking for SSE support... yes
checking for asm prefix before symbols... ""
checking whether byte ordering is bigendian... no
checking for MAP_FAILED... yes
checking for sched_yield in -lc... yes
checking for constructor attribute... yes
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking whether -export-dynamic linker flag is supported... yes
checking for dlopen in -ldl... no
checking soundcard.h usability... no
checking soundcard.h presence... no
checking for soundcard.h... no
checking sys/soundcard.h usability... yes
checking sys/soundcard.h presence... yes
checking for sys/soundcard.h... yes
checking machine/soundcard.h usability... no
checking machine/soundcard.h presence... no
checking for machine/soundcard.h... no
checking linux/soundcard.h usability... no
checking linux/soundcard.h presence... no
checking for linux/soundcard.h... no
checking for supported ALSA version for digital sound... no
checking for supported ALSA version for MIDI... no
checking for esd-config... /usr/local/bin/esd-config
checking for esd_open_sound... yes
checking for artsc-config... /usr/local/bin/artsc-config
checking for arts_init... yes
checking for alOpenPort in -laudio... no
checking for soundcard.h... (cached) no
checking for sys/soundcard.h... (cached) yes
checking for machine/soundcard.h... (cached) no
checking for linux/soundcard.h... (cached) no
checking linux/awe_voice.h usability... no
checking linux/awe_voice.h presence... no
checking for linux/awe_voice.h... no
checking sys/procfs.h usability... yes
checking sys/procfs.h presence... yes
checking for sys/procfs.h... yes
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for XMissingExtension in -lXext... yes
checking X11/xpm.h usability... yes
checking X11/xpm.h presence... yes
checking for X11/xpm.h... yes
checking for XpmCreatePixmapFromData in -lXpm... yes
checking for XcursorImageCreate in -lXcursor... yes
checking for XShmQueryExtension in -lXext... yes
checking for XF86VidModeQueryExtension in -lXxf86vm... yes
checking for XDGAQueryExtension in -lXxf86dga... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... no
checking for pkg-config... /usr/local/bin/pkg-config
Package jack was not found in the pkg-config search path.
Perhaps you should add the directory containing `jack.pc'
to the PKG_CONFIG_PATH environment variable
No package 'jack' found
Package jack was not found in the pkg-config search path.
Perhaps you should add the directory containing `jack.pc'
to the PKG_CONFIG_PATH environment variable
No package 'jack' found
checking for jack_client_new... no
checking for ANSI C header files... (cached) yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking whether time.h and sys/time.h may both be included... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking return type of signal handlers... void
checking for mmap... yes
checking for memcmp... yes
checking for mkstemp... yes
checking for stricmp... no
checking for strlwr... no
checking for strupr... no
checking for vprintf... yes
configure: creating ./config.status
config.status: creating makefile
config.status: creating allegro-config
config.status: creating include/allegro/platform/alunixac.h
config.status: include/allegro/platform/alunixac.h is unchanged
config.status: executing default commands
Some drivers will be built as dynamic modules.
Enabled modules: dga2 ossmidi artsdigi esddigi ossdigi
Disabled modules: jackdigi sgialdigi alsamidi alsadigi
Generated code: signals instead of threads, little endian, i386 asm, MMX, SSE
Generated libraries: shared release
Compiled programs: dynamically linked release
Ignoring compiler warnings.

configure: WARNING: You need to use GNU make to build Allegro.
configure: WARNING: This might be called gmake on your system.

hope this helps

Evert

Member #794

November 2000

The configure output looks ok to me, nothing strange there.

I have acces to SF's compile farm now so I can test things on BSD myself. It looks like the outport problem is caused by Chris' patch that always defines all graphics driver constants on UNIX.
There was a proposed fix for this not too long ago, which I'm checking now. I'll post back with the results.