Author Topic: .def & import library names  (Read 27940 times)

Offline rcrnstn

  • Single posting newcomer
  • *
  • Posts: 2
.def & import library names
« on: July 21, 2009, 02:51:49 am »
When building "Test.dll" I expect the other files to be named "libTest.def" and "libTest.a".
Instead they are called "libTest.dll.def" and libTest.dll.a". Why is this? Is it by design or am I missing something?

I am basing my project on the "Dynamic Link Library" template.
In "Project Options->Build Targets" I have ticked the "Create import library" and "Create .DEF exports file".
I also have "Auto-generate filename prefix" and "Auto-generate filename extension" ticked. My output filename is Test.dll

For now I have solved the problem by unticking "Create import library" and "Create .DEF exports file" and added
-Wl,--output-def=libTest.def
-Wl,--out-implib=libTest.a
to my "Other Link Options"

I'd appreciate any reply

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: .def & import library names
« Reply #1 on: July 25, 2009, 09:21:09 am »
I had the exact same complaint to the developer who added that "feature". The reason he added that behavior is that when you want to create an output file which is really a DLL but with another extension and dots in its name (like this.is.evil.plugin), he won't get what he wants. The current behavior works lovely for all cases (according to him). I also think this behavior is 'wrong' (as in 'it is not what one would expect to happen' and 'it is not what one wants to happen'). Although, he is willing to accept a change as long as it also works fine with his scenario. Thing is, no solution has been discussed at all.

The solution would most likely involve adding another checkbox and/or an extra text field (extension?). Ideas are welcomed.

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: .def & import library names
« Reply #2 on: October 26, 2009, 09:59:35 pm »
On the face of it, this would seem to be a simple problem to fix - i.e. if the target DLL has a non-standard extension, append ".dll.a" or ".dll.def" or whatever is appropriate. But if its extension is the standard ".dll" just replace that extension with ".lib", ".a" or ".def". Or even better - allow the user some choice.

In any case, this only seems to be a problem when certain compilers are selected. If it can work sensibly with some compiler selections why can't it be made to work sensibly for the others???

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: .def & import library names
« Reply #3 on: October 27, 2009, 06:53:56 am »
But if its extension is the standard ".dll" just replace that extension with ".lib", ".a" or ".def". Or even better - allow the user some choice.
It's not as easy as that. You have to take into consideration the user's ability to have C::B autogenerate the prefix and extension.

So - Ceniza:
As I am unaware to find what I am looking for... I nned two posts as reference:
1.) The one of TDragon where he explains the required handling with the MinGW/GCC compiler
2.) Your post with a first suggestion about "required checkboxes".
[Edit]: 3.) Not to forget: The SVN revision where this change was introduced. :lol:

Hence where are they??? :?
« Last Edit: October 27, 2009, 06:57:47 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: .def & import library names
« Reply #4 on: October 27, 2009, 08:52:43 am »
It's not as easy as that. You have to take into consideration the user's ability to have C::B autogenerate the prefix and extension.

Morten - I don't understand how that complicates the situation. Can you give an example?

My perspective (which admittedly hasn't had much thought put into it) goes something like this:-

1) Regardless of how the target DLL's extension gets generated, it will either be standard or non-standard.
2) If it's non-standard, append ".a" or ".lib" or ".def" (or whatever) when generating the link library and def files.
3) Alternatively, if it's the standard ".dll" or ".so" replace the extension, instead of appending a further extension (or at least offer this as an option).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: .def & import library names
« Reply #5 on: October 27, 2009, 09:26:25 am »
Morten - I don't understand how that complicates the situation. Can you give an example?
Please wait until Ceniza answers. This will clarify things.
Basically the "bug" is in wxWidgets. We use wx functions to obtain the extension of a file. If you do that on a file like "System.Core.Dll" you get ".Dll". But if you do it on "System.Core" you get ".Core" as an extension! To make things even more complicated think about "App.Paint.Plugin" which shall actually be a DLL but with a different extension. So how would you differ (taking into account that the user has triggered "auto extension on") whether this is the real extension the user wants or not?
Ceniza once proposed a good UI way how to handle this. TDragon proposed how to "tell" the MinGW/GCC compiler what to do. We can continue the discussion once we re-collected this information.
« Last Edit: October 27, 2009, 09:29:07 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: .def & import library names
« Reply #6 on: October 27, 2009, 08:10:32 pm »
What am I supposed to answer? How's it supposed to clarify things? I am lost (and tired).

Offline thedmd

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: .def & import library names
« Reply #7 on: February 13, 2010, 11:32:31 pm »
You can restore old behaviour by applying path included bellow. I must note that it is a hack and should not be used without a reason. Since there is no alternative for this moment it is acceptable.

My proposition is simple: add to build system functions that are responsible for returning names of import library and definition file.

Code
wxString CompileTargetBase::GetDynamicLibImpFilename() const;

There is a thing that I cannot understand. If CompileTargetBase class contain functions for building target names, why CompilerCommandGenerator don't use them?



Not it is time to path:

Revision: 5480

To change this anoying behaviour replace:
Code
        wxString current_ext   = fname.GetExt();
        wxString requested_ext = compiler->GetSwitches().libExtension;
        if      (   (platform::windows && !current_ext.IsSameAs(requested_ext, false))
                 || (!current_ext.IsSameAs(requested_ext)) )
        {
            // Note: Do not use SetExt here to handle libs like e.g. System.Core correctly.
            // Otherwise SetExt would result in System.dll instead of System.Core.dll
            fname.SetFullName(fname.GetFullName()+wxFILE_SEP_EXT+requested_ext);
        }

To:
Code
        fname.SetExt(compiler->GetSwitches().libExtension);
"God starts from scratch too"

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: .def & import library names
« Reply #8 on: February 14, 2010, 11:30:42 am »
To change this anoying behaviour replace:
Keep in mind that this also re-introduces the bug mentioned in the comment. So you won't be able to create certain library files anymore that follow a different naming scheme.

I still believe the current behavior is more correct as it is not a bug.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline thedmd

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: .def & import library names
« Reply #9 on: February 14, 2010, 12:01:00 pm »
I agree with you. Current behavior is safer for multiplatform libraries, but have one big disadvantage: violate the standard.

I wish to see additional text field which allow to type in name of import library. That will be sufficient. Example for hypothetical project “FooBar”:

Import library: $(OutDir)$(TargetFileName)$(DefaultImportExtension)

Where:
MacroWindowsLinux
$(OutputDir)C:\Project\foobar-0.0.1\\home\project\foobar-0.0.1\
$(TargetName)foobarfoobar
$(TargetFileName)foobar.dllfoobar.so
$(DefaultImportExtension).lib.a

If the user wish he/she can replace $(TargetFileName) with $(TargetName) and we got old behavior.

It this good enough idea to be introduced into C::B? I propose same operation for .def files.
« Last Edit: February 14, 2010, 12:05:03 pm by thedmd »
"God starts from scratch too"

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: .def & import library names
« Reply #10 on: February 14, 2010, 05:40:01 pm »
If the user wish he/she can replace $(TargetFileName) with $(TargetName) and we got old behavior.
Look: It is not as simple as this.
If a user selects "App.Plugin" as a library name you don't know if (s)he wants to have a "Ap.Plugin.dll" or really just "App.Plugin". So querying any extension (by using GetExt()) will not work reliable as for a file like "App.Plugin" it will return "Plugin" as extension which is most likely not intended. Ceniza once posted a solution with another checkbox option that would really enable to setup exactly how the file name should look like and TDragon once posted how GCC "expects" the library extensions. However, I don't find these posts anymore, so I asked Ceniza to have a look at his history here:
Ceniza once proposed a good UI way how to handle this. TDragon proposed how to "tell" the MinGW/GCC compiler what to do. We can continue the discussion once we re-collected this information.
...but he didn't answer yet. :-(

From my point of view that was the only acceptable solution so far as it allows for any file naming scheme.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline thedmd

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: .def & import library names
« Reply #11 on: February 14, 2010, 06:02:48 pm »
Yep, it is not simple also it is not that hard. I think C::B should allow to choose what user want to got.

Why Set/GetExt are used at the first place for generating target filenames, if CompilerTargetBase is able to provide sufficient information? I found that the name of import library and definition file are computed from target name by using SetExt(). Did I miss something important?
"God starts from scratch too"

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: .def & import library names
« Reply #12 on: February 14, 2010, 06:37:25 pm »
Look: It is not as simple as this.
If a user selects "App.Plugin" as a library name you don't know if (s)he wants to have a "Ap.Plugin.dll" or really just "App.Plugin".

But there's a check box that allows the user to determine whether or not the extension should be auto-generated. If (s)he checks the box and types "App.Plugin" then (s)he'll get "App.Plugin.dll". If (s)he doesn't check the box there should be an assumption that the typed extension (if there is one) is the intended extension. And if there isn't a typed-in extension, then it does whatever it does now. Really Morten I think you're finding complications where there aren't any.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: .def & import library names
« Reply #13 on: February 14, 2010, 07:47:20 pm »
Really Morten I think you're finding complications where there aren't any.
Sorry, but I insist that this needs to be implemented correctly. Again: the only correct way I see is the one proposed by Ceniza... wherever that was. But I recall that I made my mind with that suggestion.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline johne53

  • Regular
  • ***
  • Posts: 253
Re: .def & import library names
« Reply #14 on: February 14, 2010, 07:52:28 pm »
When/where did Ceniza propose something? There's no proposal in this thread AFAICT.