problem. Anyway, it should be no problem to use g++.exe as compiler.
C or C++. Additionally all public header use the C linkage spec:
> If it is looking for libintl then that is why it is failing because there is only proxy-libintl in the deps folder
looks for intl.dll. So perhaps just try renaming that file then. Or
try manually calling gcc linking command with "-lintl3".
> You obviously STILL have not read the fluidsynth user documentation where it clearly indicates that multiple sound drivers are incorporated and available.
I am aware of the docs. However you may only compile fluidsynth with
on. It is not supported compiling ALSA support on windows. This would
"snd_pcm_open()". Where should that come from if you instantiate the
> You have also STILL not had a look at eplayOrgan on my website - much less tried it out.
time is limited, so no reason for any exclamation marks or capslock.
Even if you deny it, you are compiling fluidsynth for and on windows.
Sure, that's the kind of abstraction wine provides for most windows binaries.
And this will only work for native platform builds of fluidsynth.
> Can you please put me in touch with the person you said has succeeded as I would like to know how and when he did it.
something to tell.
> How many people are there who want to give fluidsynth command line text in Chinese?
OT. I dont think this is an option for upstream btw.
2017-11-21 10:13 GMT+01:00 David Back <
address@hidden>:
> Tom
>
> I never did think it used c++ as a linker, that is just your misconception
> of what I said. Obviously it uses a linker to link.
> What I said is that it is using a c++ compiler to compile a c program and
> that maybe that is what is making the linker
> fail because it is trying to process the constructors, a feature which a c
> program does not have.
>
> If it is looking for libintl then that is why it is failing because there is
> only proxy-libintl in the deps folder libintl does not
> exist!!!! but intl.dll does exist. You have the directory listing I supplied
> - have a look.
>
> Thanks for the clarification on the -D options I will now do a few
> experinents and let you know the results.
>
> I am fully aware of the fact that alsa etc are not useable on windows - that
> is no bar to compiling a program which uses
> them on a windows system. That program can then be executed on another
> system where they are available and it should
> be able to use them. That is what I am aiming for. I am also aware that I am
> working on the leading edge of what is do-able.
>
> You obviously STILL have not read the fluidsynth user documentation where it
> clearly indicates that multiple sound drivers
> are incorporated and available, it states the order in which it looks for
> them and there is a program function which allows any
> one of them to be selected for use.
>
> You have also STILL not had a look at eplayOrgan on my website - much less
> tried it out. As I said it works on ANY
> system, not just Windows. I personally have tested it to run on Mac, Linux
> and Windows as supplied - no compilation
> or installation of any kind is needed.
>
> I am NOT trying to compile fluidsynth for use only on Windows - I expect the
> version I compile to run on ANY Mac or Linux
> system under Wine, or Windows system direct AND to be able to use the
> appropriate sound drivers for each system.
>
> David
>
> ________________________________
> From: Tom M. <
address@hidden>
> To: David Back <
address@hidden>; FluidSynth Mailing List
> <
address@hidden>
> Sent: Monday, 20 November 2017, 14:30
>
> Subject: Re: [fluid-dev] pkgconfig not found
>
> Regarding the build log, I dont see why you think it uses c++ as linker. It
> correctly calls gcc.exe, line 15. Still strange that it doesnt find libintl
> although it should be in %path%. Have no further ideas so far.
>
>> Are these cmake -D options? I will try them later.Do you mean for example
>> "cmake -DCMAKE_LINKER=gcc.exe"
>
> Anyway, yes, that would be the correct useage.
>
>
> Even if you manage it to get "appropriate header files" for all audio
> drivers, against which libraries would you link in order to create that
> single dll, given the fact that alsa, oss and coreaudio are not available on
> windows?
>
>
> Tom
>
> Am Montag, 20. November 2017, 12:58:14 CET schrieb David Back:
>>
>> Tom
>> Herewith attached the build.log as requested. I had to redirect stderr to
>> the file as well otherwise the interestingbit was not recorded in the file.
>> I do not understand your CMAKE_LINKER etc. Are these cmake -D options? I
>> will try them later.Do you mean for example "cmake -DCMAKE_LINKER=gcc.exe"
>> Compiling support for other (foreign to windows) sound systems is just a
>> matter of using the appropriateheader files. No problem at all. I am already
>> compiling similar support for foreign midi inputs into my project.Obviously
>> it wont use the interfaces when the program is run on windows but it can use
>> them when it isrun on other operating systems. Read the fluidsynth user
>> documentation and read up about, or even trymy eplayOrgan which uses four
>> instances of fluidsynth. See
https://midimusic.github.io/and can redirect
>> each output to a different sound driver.
>> eplayOrgan will run on ANY system as supplied, without any recompiling or
>> other changes.
>> Good luck with the build.log
>> David
>> From: Tom M. <
address@hidden>
>> To: David Back <
address@hidden>
>> Cc:
address@hidden>> Sent: Sunday, 19 November 2017, 15:57
>> Subject: Re: [fluid-dev] pkgconfig not found
>>
>> It uses c++ as linker? No matter 1.1.6, 1.1.7 or master? Shouldnt happen.
>> I think it's time for a full build log:
>>
>> cmake -DCMAKE_VERBOSE_MAKEFILE=1 ..
>> make > build.log
>>
>> You can try setting these cmake variables to gcc.exe
>> CMAKE_LINKER
>> CMAKE_C_LINK_EXECUTABLE
>> CMAKE_CXX_LINK_EXECUTABLE
>>
>> > Cmake is trying to make a working program ONLY for the system it is
>> > running on which is NOT what I want to do.
>>
>> But this is exactly how cross platform deployment works. I dont understand
>> why you want to bundle all audio drivers (even foreign ones) in a single
>> dll. Think about it: How would you compile fluidsynth with ALSA or OSS
>> support on windows? The ABI and calling conventions between different OSs
>> vary. I dont see how this could work.
>>
>> And unless you want to privately fork fluidsynth, writing a custom
>> makefile is IMO the worst choice you could make. If upstream changes
>> anything related to the buildsystem your build will break.
>>
>> Tom
>>
>>
>> Am Sonntag, 19. November 2017, 15:40:58 CET schrieben Sie:
>> > Hi Tom
>> > I am now working with version 1.1.8. which has the same linker problem
>> > as all the others.
>> > Thanks for your reply and am interested and surprised to hear that you
>> > do not have any solution to thelinker errors.
>> > Having done a bit of research it appears to me (and I could easily be
>> > wrong) that the problem liesin compiling fluidsynth with a c++ compiler when
>> > the header files indicate to me that the program is writtenin plain old C.
>> > (Please tell me if I am wrong.)
>> > The linker is looking to generate extra code which initialises all the
>> > c++ constructors it finds. (Presumably thisis the only way to initialise a
>> > .dll ). The fact that it does not find ANY constructors is probably causing
>> > the error.(Inserting a dummy constructor may cure the problem).
>> > I think the solution may be to compile fluidsynth with a C compiler.
>> > Does cmake have any option to force usingC rather than c++. I tell it -G
>> > "MinGW Makefiles" (there is no other useful option) so it does not know
>> > whetherit is working with C or c++ so it goes for c++ which can (in theory)
>> > do both.
>> > I will have to investigate portaudio. I am currently in learning mode
>> > regarding audio interfaces but it would seemto me that fluidsynth DOES have
>> > the capability to contain ALL of the common audio interfaces (for Mac,
>> > Linux,and Windows) and the interface it uses depends upon which one it finds
>> > first when it is run. This is documentedin fluidsynth's user documentation.
>> > Cmake is trying to make a working program ONLY for the system it is
>> > running on which is NOT what I want todo. I suspect it would be best for me
>> > to write my own makefile and I can then put what I want into it. This
>> > willavoid me trying to understand the mess (which usually does work) that
>> > cmake creates.
>> > Best WishesDavid.
>> >
>> > From: Tom M. <
address@hidden>
>> > To: David Back <
address@hidden>
>> > Cc: FluidSynth Mailing List <
address@hidden>
>> > Sent: Saturday, 18 November 2017, 12:35
>> > Subject: Re: [fluid-dev] pkgconfig not found
>> >
>> > Ok, good to hear. You should however use 1.1.8 for your testings, as the
>> > older versions are unsupported. For those linker errors I currently cant
>> > provide a solution.
>> >
>> > > I will need some extra packages to get Pulseaudio and otherLinux and
>> > > mac sound drivers incorporated.
>> >
>> > Sry, never attempted to make pulseaudio run on windows myself.
>> >
>> > > The whole purpose of thisexercise is to get a fluidsynth.dll which has
>> > > ALL the sound drivers available so it SHOULD work on allsystems (under Wine)
>> > > with minimum latency.
>> >
>> > That would be awful job I guess, you should consider simply using
>> > portaudio, as it provides exactly that kind of abstraction.
>> >
>> > Tom
>>
>>
>>
>>
>
>
>
>