Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4.2.1 compiler test

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Allegro 4.2.1 compiler test
kazzmir
Member #1,786
December 2001
avatar

Evert, your last patch fixes the problem for me.

juvinious
Member #5,145
October 2004
avatar

I still had to make install-fixbundle before make install to get it to work. :(

$ sudo make install
Password:
misc/mdhelper.sh /usr/local/lib /usr/local/include /usr/local/include/allegro /usr/local/include/allegro/platform /usr/local/include/allegro/internal /usr/local/include/allegro/inline /usr/local/bin
install lib/macosx/liballeg-4.2.1.dylib /usr/local/lib
(cd /usr/local/lib; ln -s -f liballeg-4.2.1.dylib liballeg-4.2.dylib)
(cd /usr/local/lib; ln -s -f liballeg-4.2.1.dylib liballeg-4.dylib)
(cd /usr/local/lib; ln -s -f liballeg-4.2.1.dylib liballeg.dylib)
install -d /usr/local/lib
install lib/macosx/liballeg-main.a /usr/local/lib
ranlib /usr/local/lib/liballeg-main.a
install -d /usr/local/bin
allegro-config script created in /usr/local/bin
make: *** No rule to make target `/usr/local/bin/fixbundle', needed by `generic-install'.  Stop.

__________________________________________
Paintown

kazzmir
Member #1,786
December 2001
avatar

You didnt apply the patch.

juvinious
Member #5,145
October 2004
avatar

Obviously, I misunderstood and I thought it was applied to the repository. ::)
/me cleans it out and tries again

[edit]
Ok it works. :)

__________________________________________
Paintown

Evert
Member #794
November 2000
avatar

Great; I'll commit it later today when I'm back home.

EDIT: Commited.

Jakub Wasilewski
Member #3,653
June 2003
avatar

GCC 3.4.2 (MinGW) under Windows XP Professional. Everything OK with the compilation stage. I tested binary compatibility using some of my games and the compiled examples from 4.2.0, no problems whatsoever.

---------------------------
[ ChristmasHack! | My games ] :::: One CSS to style them all, One Javascript to script them, / One HTML to bring them all and in the browser bind them / In the Land of Fantasy where Standards mean something.

Evert
Member #794
November 2000
avatar

Ok, good to know. I should finally have some time to do a third RC tomorrow or the day after.

Andrei Ellman
Member #3,434
April 2003

Evert said:

I should finally have some time to do a third RC tomorrow or the day after.

I've just posted a patch to the [AD] list that fixes two issues with pack_fopen_chunk(). Could you make sure it is included?

AE.

--
Don't let the illegitimates turn you into carbon.

drwook
Member #7,800
September 2006

Well, I get this during 'make' on linux (x86_64) with gcc 4.1.1 - just me?;

gcc -DALLEGRO_MODULES_PATH=\"/usr/local/lib/allegro\" -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro -DALLEGRO_LIB_BUILD -mtune=k8 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused -fPIC -DALLEGRO_SHARED -DALLEGRO_MODULE -c ./src/unix/jack.c -o obj/unix/module/jack.o
gcc -shared -fPIC -DALLEGRO_SHARED -o lib/unix/alleg-jackdigi.so obj/unix/module/jack.o -L/usr/lib64 -Wl,--export-dynamic `pkg-config --libs jack`
gcc -DALLEGRO_MODULES_PATH=\"/usr/local/lib/allegro\" -DHAVE_CONFIG_H -I. -Iinclude -Iinclude/allegro -I./include -I./include/allegro -DALLEGRO_LIB_BUILD -mtune=k8 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -Wall -Wno-unused -c ./setup/setup.c -o obj/unix/setup.o
gcc -s -L/usr/lib64 -Wl,--export-dynamic -o setup/setup obj/unix/setup.o -Llib/unix -lalleg-4.2.1 -lalleg_unsharable -lm
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_486'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_cpuid_supported'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_cx_w'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_cyrix'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_is_fpu'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_get_cpuid_info'
lib/unix/liballeg-4.2.1.so: undefined reference to `_i_cx_r'
collect2: ld returned 1 exit status
make: *** [setup/setup] Error 1

kazzmir
Member #1,786
December 2001
avatar

Did you pass any options to ./configure ?

I have an amd64 too and I have no problems, but I pass --disable-asm to configure.

drwook
Member #7,800
September 2006

I get that passing no options, just testing --disable-asm...

...

Same :(

I'm running glibc 2.4, I'm assuming there's no dependancy on linuxthreads or other problem related to that?

Here's the output I get from './configure' in case it's useful (looks sane to me, but as something's wrong it might be here! )

checking for gcc... gcc
checking for C compiler default output file name... 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... amd64
checking whether -mtune is supported... 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... yes
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... yes
checking linux/soundcard.h presence... yes
checking for linux/soundcard.h... yes
checking for _oss_ioctl in -lossaudio... no
checking for supported ALSA version for digital sound... yes
checking for supported ALSA version for MIDI... yes
checking for esd-config... /usr/bin/esd-config
checking for esd_open_sound... yes
checking for artsc-config... no
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) yes
checking linux/awe_voice.h usability... yes
checking linux/awe_voice.h presence... yes
checking for linux/awe_voice.h... yes
checking for _oss_ioctl in -lossaudio... (cached) no
checking for OSS sequencer support... yes
checking sys/procfs.h usability... yes
checking sys/procfs.h presence... yes
checking for sys/procfs.h... yes
checking for getexecname in -lc... no
checking for X... libraries /usr/lib64, headers
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 for XOpenIM in -lX11... yes
checking sys/io.h usability... yes
checking sys/io.h presence... yes
checking for sys/io.h... yes
checking linux/joystick.h usability... yes
checking linux/joystick.h presence... yes
checking for linux/joystick.h... yes
checking linux/input.h usability... yes
checking linux/input.h presence... yes
checking for linux/input.h... yes
checking linux/fb.h usability... yes
checking linux/fb.h presence... yes
checking for linux/fb.h... yes
checking vga.h usability... no
checking vga.h presence... no
checking for vga.h... no
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for pkg-config... /usr/bin/pkg-config
checking for jack_client_new... yes
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 mprotect... 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
checking for stat64... yes
configure: creating ./config.status
config.status: creating makefile
config.status: creating allegro-config
config.status: creating include/allegro/platform/alunixac.h
config.status: executing default commands
Some drivers will be built as dynamic modules.
Enabled modules: dga2 jackdigi fbcon ossmidi esddigi alsamidi alsadigi ossdigi
Disabled modules: svgalib vbeaf vga sgialdigi artsdigi
Generated code: multithreaded, little endian, amd64 asm
Generated libraries: shared release
Compiled programs: dynamically linked release
Ignoring compiler warnings.
X11 support: enabled with: Xext Xpm Xcursor XShm XF86VidMode XDGA XIM
Linux console support: enabled

Thomas Fjellstrom
Member #476
June 2000
avatar

Try doing a "make clean", then start over. and if that still errors, do a make distclean. and make sure config.cache isn't around before you ./configure

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

drwook
Member #7,800
September 2006

Same after 'make distclean'...

I'll start randomly disabling things to try to work out what's breaking here :) But feel free to throw suggestions my way if anyone has any ideas?

Evert
Member #794
November 2000
avatar

Quote:

I have an amd64 too and I have no problems, but I pass --disable-asm to configure.

You don't need to pass --disable-asm, it's implied (well, there is one asm routine in there: it wraps the CPUID instruction). I have an AMD64 as well and can confirm that it works for me.
However, I don't have GCC 4.1.

Milan Mimica
Member #3,877
September 2003
avatar

"make depend" should do, though I think it's implicated by "make distclean"

drwook
Member #7,800
September 2006

Hmm... Can confirm same behaviour with gcc 3.4.6 and a 4.2.0 development build I have hanging around. Must be something to do with my system as nobody else seems to have seen this... Dependancy issue perhaps...

Evert
Member #794
November 2000
avatar

Hmm... just to have asked, your system is running in 64 bit mode, right?
To the best of my knowledge, it should work in 32 bit mode, but if it detects and AMD64, assumes a 64 bit environment but uses the 32 bit dependencies (or the other way around, uses 32 bit dependencies while compiling the 64 bit library in 32 bit mode), that may cause the problem.

drwook
Member #7,800
September 2006

Well I've rebuilt dependancies, and can now compile happily if I pass --disable-asm to configure - is this expected behaviour? How's it implying this if I shouldn't have to pass it, as it appears not to in my case?

Evert
Member #794
November 2000
avatar

Quote:

Well I've rebuilt dependancies, and can now compile happily if I pass --disable-asm to configure - is this expected behaviour?

It most definately is not.
From a frechly unpacked archive, Allegro should build normally when you run

./fix.sh unix 
./configure
make

That's it. Anything more than that indicates a problem with the build process. Using an Allegro release (note: not a snapshot) you should never need to run make depend and you should never need to pass options to configure to compile Allegro. You most certainly should never need to pass --disable-asm.

Quote:

How's it implying this if I shouldn't have to pass it, as it appears not to in my case?

Compiling on AMD64 automatically implies --disable-asm, since all the asm code is 32 bit assembler and incompatible with a 64 bit library.

Anyway, you didn't answer my question:

I said:

just to have asked, your system is running in 64 bit mode, right?

drwook
Member #7,800
September 2006

Yes I'm running native 64 bit.

I realise the asm is 32 bit, and so necessarily can't be built into a 64 bit binary. What I meant was, how does configure determine it's running on a 64 bit platform? As it appears to be failing that detection on my system.

I took a look at the configure script, but was pretty tired last night and got a little lost :)

Evert
Member #794
November 2000
avatar

Quote:

What I meant was, how does configure determine it's running on a 64 bit platform?

At the top of aclocal.m4:

1# Place m4 macros here.
2 
3dnl
4dnl Test for processor type.
5dnl
6dnl Variables:
7dnl allegro_cv_processor_type=(i386|sparc|unknown)
8dnl
9AC_DEFUN(ALLEGRO_ACTEST_PROCESSOR_TYPE,
10[AC_BEFORE([$0], [ALLEGRO_ACTEST_SUPPORT_MMX])
11AC_MSG_CHECKING(for processor type)
12AC_CACHE_VAL(allegro_cv_processor_type,
13[AC_TRY_COMPILE([], [asm (".globl _dummy_function\n"
14"_dummy_function:\n"
15" pushl %%ebp\n"
16" movl %%esp, %%ebp\n"
17" leal 10(%%ebx, %%ecx, 4), %%edx\n"
18" call *%%edx\n"
19" addl %%ebx, %%eax\n"
20" popl %%ebp\n"
21" ret" : :)],
22allegro_cv_processor_type=i386,
23AC_TRY_COMPILE([], [asm (".globl _dummy_function\n"
24"_dummy_function:\n"
25" save %%sp, -120, %%sp\n"
26" ld [[%%fp-20]], %%f12\n"
27" fitod %%f12, %%f10\n"
28" faddd %%f10, %%f8, %%f8\n"
29" ret\n"
30" restore" : :)],
31allegro_cv_processor_type=sparc,
32AC_TRY_COMPILE([], [asm (".globl _dummy_function\n"
33"_dummy_function:\n"
34" pushq %%rbp\n"
35" movl %%esp, %%ebp\n"
36" leal 10(%%ebx, %%ecx, 4), %%edx\n"
37" callq *%%rdx\n"
38" addl %%ebx, %%eax\n"
39" popq %%rbp\n"
40" ret" : :)],
41allegro_cv_processor_type=amd64,
42allegro_cv_processor_type=unknown)))])
43AC_MSG_RESULT($allegro_cv_processor_type)])

Now... if they've changed the asm syntax (*again*) then maybe that can fail. Can you try it manually and see if it compiles?
On the other hand, looking at your configure output, it appears to detect the processor type just fine:

Quote:

checking for processor type... amd64

EDIT: remember to re-run autoconf if you make changes to aclocal.m4 or configure.in

drwook
Member #7,800
September 2006

No, that certainly compiles and seems to give the expected output... Very odd... Haven't managed to find anything obvious causing the problem, but will try to take a proper look later as I have to dash off for a few hours.

(have found a few other people with this issue on amd64, but still appears to be a very small minority)

Evert
Member #794
November 2000
avatar

Can you post the linker line that links the library?
The problem is with the CPU detection (this is the only difference between the AMD64 build and a generic C build). The CPU detection code used is in src/i386/icpu.c, with helper functions in src/amd64/acpus.s (most of these are dummy functions).
Can you check if acpus.s is properly compiled and linked in? Can you check the symbol names in the generated .o file? configure claims there is no prefix, so they should have the proper names, but best to double check that.

Milan Mimica
Member #3,877
September 2003
avatar

Just wanted to point out that makefile for MSVC (and possibly other makefiles, I didn't check) are incompatible with make-3.81. Version 3.80 works. `make' says : "makefile.vc:258: *** target pattern contains no `%'. Stop."

I think it needs to be fixed before 4.2.1 is released because everyone will start using 3.81 soon.

Makefile for unix is fine.

Evert
Member #794
November 2000
avatar

Sure. Do you have a fix?
I won't be looking into this (no time).

 1   2   3 


Go to: