> 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 <csw...@yahoo.co.uk>: > 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. <tom.m...@googlemail.com> > To: David Back <csw...@yahoo.co.uk>; FluidSynth Mailing List > <fluid-dev@nongnu.org> > 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. <tom.m...@googlemail.com> >> To: David Back <csw...@yahoo.co.uk> >> Cc: fluid-dev@nongnu.org >> 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. <tom.m...@googlemail.com> >> > To: David Back <csw...@yahoo.co.uk> >> > Cc: FluidSynth Mailing List <fluid-dev@nongnu.org> >> > 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 >> >> >> >> > > > > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
