Using configure --build= link failure

Andrew C
  • Andrew C

    Andrew C - 2012-02-27

    I'm trying to compile bristol 0.60.9 on an Intel Atom processor for i386 processors using the -build=i386, as I'm wanting to run it on at least the Atom, Pentium D and Intel 2 Core Duo processors that I happen to have here, from a livecd, so I figure trying to compile bristol for i386 or even i586 should do the trick.

    Problem is, when running make, LD returns a collect error. Do I need cross compile tools or should this be possible  with standard GCC?

    libtool produces the following:

    libtool: link: gcc -pthread -Wall -g -I./../include/slab -I./../include/bristol -I. -DBRISTOL_VOICECOUNT=32 -DBRISTOL_RAMP_RATE=10 -DBRISTOL_LIN_ATTACK -D_BRISTOL_DRAIN -D_BRISTOL_JACK -D_BRISTOL_JACK_MIDI -D_BRISTOL_JACK_SESSION -DBRISTOL_HAS_ALSA=1 -I/usr/include/alsa -ffast-math -fomit-frame-pointer -O2 -g -O2 -I/usr/X11R6/include -Bdynamic -o bristol aksdco.o aksenv.o aksfilter.o aksreverb.o arpdco.o audioEngine.o audiothread.o bristolaks.o bristolarp2600.o bristolaxxe.o bristoldx.o bristolexplorer.o bristolhammond.o bristoljuno.o bristol.o bristolmemorymoog.o bristolmixer.o bristolmm.o bristolobx.o bristolodyssey.o bristolpoly6.o bristolpoly.o bristolprophet52.o bristolprophet.o bristolsampler.o bristolsystem.o bristolvox.o dca.o dco.o dimensionD.o dxop.o electroswitch.o envelope.o expdco.o filter2.o filter.o follower.o hammond.o hammondchorus.o hpf.o junodco.o lfo.o midihandlers.o midinote.o midithread.o noise.o prophetdco.o resonator.o reverb.o ringmod.o rotary.o sdco.o sdcoutils.o soundManager.o thesermon.o vibrachorus.o vox.o bristolsolina.o bristolroadrunner.o bristolgranular.o granulardco.o bristolrealistic.o bristoljupiter.o bristolbitone.o bit1osc.o arpeggiator.o bristolcs80.o activesense.o cs80osc.o blo.o bristolprophet1.o cs80env.o bristolsonic6.o bristoltrilogy.o trilogyosc.o bristolpoly800.o env5stage.o nro.o bristolbme700.o bristolbassmaker.o bristolsid1.o bristolsid2.o ringbuffer.o  -L/source/bristol-0.60.9/libbristolmidi/.libs -L/source/bristol-0.60.9/libbristolaudio/.libs -L/source/bristol-0.60.9/libbristol/.libs -L/source/bristol-0.60.9/libbristolic /source/bristol-0.60.9/libbristolmidi/.libs/libbristolmidi.a /source/bristol-0.60.9/libbristolaudio/.libs/libbristolaudio.a /usr/lib/ -ldl -lrt -ljack /source/bristol-0.60.9/libbristolic/.libs/libbristolic.a /source/bristol-0.60.9/libbristol/.libs/libbristol.a -lm -lpthread -pthread
    /source/bristol-0.60.9/libbristol/.libs/libbristol.a(audioRoutines.o): In function `bristolAudioClose':
    /source/bristol-0.60.9/libbristol/audioRoutines.c:61: undefined reference to `audioClose'
    /source/bristol-0.60.9/libbristol/.libs/libbristol.a(audioRoutines.o): In function `bristolAudioOpen':
    /source/bristol-0.60.9/libbristol/audioRoutines.c:115: undefined reference to `audioOpen'
    /source/bristol-0.60.9/libbristol/.libs/libbristol.a(audioRoutines.o): In function `bristolAudioStart':
    /source/bristol-0.60.9/libbristol/audioRoutines.c:128: undefined reference to `setAudioStart2'
    /source/bristol-0.60.9/libbristol/.libs/libbristol.a(audioRoutines.o): In function `bristolAudioWrite':
    /source/bristol-0.60.9/libbristol/audioRoutines.c:186: undefined reference to `audioWrite'
    /source/bristol-0.60.9/libbristol/.libs/libbristol.a(audioRoutines.o): In function `bristolAudioRead':
    /source/bristol-0.60.9/libbristol/audioRoutines.c:244: undefined reference to `audioRead'
    collect2: ld returned 1 exit status
    make: ***  Error 1
    make: Leaving directory `/source/bristol-0.60.9/bristol'
    make: ***  Error 1
    make: Leaving directory `/source/bristol-0.60.9'
    make: ***  Error 2


  • Nick Copeland

    Nick Copeland - 2012-02-27

    All of the failing routines are from libbristolaudio, I assume that is compiled? You should see the .o files and in  the directory if it worked.

    Alternatively there is something else here. Check out this extract from your debugs:

    -L/source/bristol-0.60.9/libbristolmidi/.libs -L/source/bristol-0.60.9/libbristolaudio/.libs -L/source/bristol-0.60.9/libbristol/.libs -L/source/bristol-0.60.9/libbristolic /source/bristol-0.60.9/libbristolmidi/.libs/libbristolmidi.a /source/bristol-0.60.9/libbristolaudio/.libs/libbristolaudio.a

    These are some of the libraries that you need to link against.  libristolmidi is there as a -L option but libbristolaudio is not actually listed as a -L option, you only have the library. Can't think of any reason why that should happen, I think it would require some changes to the make files although I would not rule out some unique ./configure parameters.

    Regards, nick

  • Nick Copeland

    Nick Copeland - 2012-02-27

    You said this is an atom port. That should not matter if you have linux underneath. There was some Mac ports underway which wanted to use CoreAudio/CoreMidi, they would need these two specific libraries of mine to be rewritten for OS-X. They would still have to be included in the build though since other libraries make calls to these libraries, ie, they are dependent on it.

    Regards, nick.

  • Andrew C

    Andrew C - 2012-02-27

    It appears some changes to the makefiles need to be made, as it seems that both libbristol and libbristolaudio are compiled:

    root@AndrewLaptop:/source/bristol-0.60.9# ls libbristolaudio/
    audioEngineALSA.c   audioEngine.lo     audioGUIALSA.o  audioMastering.c
    audioEngineALSA.lo  audioEngine.o      audioGUI.c      audioMastering.lo
    audioEngineALSA.o   audioEngineOSS.c   audioGUI.lo     audioMastering.o
    audioEngine.c       audioEngineOSS.lo  audioGUI.o
    audioEngineJack.c   audioEngineOSS.o   audioGUIOSS.c   Makefile
    audioEngineJack.lo  audioGUIALSA.c     audioGUIOSS.lo
    audioEngineJack.o   audioGUIALSA.lo    audioGUIOSS.o
    root@AndrewLaptop:/source/bristol-0.60.9# ls libbristol
    audioRoutines.c   bristolcdefs.lo  debugging.o     opmgt.c
    audioRoutines.lo  bristolcdefs.o  mixroutines.c   opmgt.lo
    audioRoutines.o   debugging.c      Makefile       mixroutines.lo  opmgt.o
    bristolcdefs.c    debugging.lo    mixroutines.o

    Regarding the port, yeah, I do want at least the knowledge that if I've compiled it specifically for an intel arch that's older than any of the ones I currently have, I won't get a bunch of segfaults from trying to run an Atom built binary on a Pentium D!

    Though, would globally setting -mArch= be an alternative (I know that some distros support appending options to gcc through a file in /etc for every single invocation of it regardless)?



Log in to post a comment.