Re: [fluid-dev] pkgconfig not found

[Tom M.]

> I never did think it used c++ as a linker

Ok seems like I mixed that up because we were talking about a linkage
problem. Anyway, it should be no problem to use g++.exe as compiler.
GCC uses the file extension of a source file to determine whether it's
C or C++. Additionally all public header use the C linkage spec:
https://github.com/FluidSynth/fluidsynth/blob/c0cd1887db17b5d31aa07fe27814480850ae89ac/include/fluidsynth/audio.h#L24-L26


> If it is looking for libintl then that is why it is failing because there is 
> only proxy-libintl in the deps folder

-lintl should definitily be looking for libintl.dll, not sure if it
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
audio drivers that are available on the platform/OS you are compiling
on. It is not supported compiling ALSA support on windows. This would
require the dll to have some symbol reference to a function
"snd_pcm_open()". Where should that come from if you instantiate the
dll on windows that doesnt provide an appropriate shared lib that
contains all those ALSA functions?


> You have also STILL not had a look at eplayOrgan on my website - much less 
> tried it out.

I had downloaded the zip, unpacked it and saw a libfluidsynth.dll;
time is limited, so no reason for any exclamation marks or capslock.


> I am NOT trying to compile fluidsynth for use only on Windows

Even if you deny it, you are compiling fluidsynth for and on windows.

> I expect the version I compile to run on ANY Mac or Linux system under Wine

Sure, that's the kind of abstraction wine provides for most windows binaries.

> ...AND to be able to use the appropriate sound drivers for each system

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.

These guys are on the mailing list, they will speak up if they have
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.


Tom


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
>>
>>
>>
>>
>
>
>
>